TheBlindCow

FreeSoftware to the fullest!

Category: GNU/Linux

Tracking a QObject’s life

Why?

One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.

How?

We attach into any QObject the developer requests and monitor it (and optionally all it’s children).

To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.

What?

This is the repository:https://phabricator.kde.org/source/kobjecttracking/.

This allows us to see:

  • Spurious property change notifications
  • Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
  • How a change in a value can have an effect on other properties

At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times

Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.

Future

An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.

Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.

What do you think? Do you think it’s useful?
Feedback very welcome.

A laptop by KDE

Earlier this year we announced a joint venture between KDE and Slimbook that we named the KDE Slimbook.

Last Akademy we had the opportunity to meet the Slimbook team and discuss its purpose and future. I’m quite happy about the discussions, here’s my feedback.

KDE Slimbook

Why?

Before talking about future stuff, let’s set the context.

Personally, this has been a long-standing pet-peeve of mine. We create software solutions for virtual hardware specifications. We require our users to go the extra mile by replacing the manufacturer’s operating system, often with some annoyances because their hardware isn’t properly supported. This is not necessarily our fault, but most of us agree that we should improve this situation.

On the software side of things, while it’s our area of expertise, we are still far from being able to deliver the product we would like to give. Our ecosystem is still complex and our users have to take several decisions, some of dubious nature.

Hence, I started pushing for this project with some colleagues from KDE.

Where are we?

As discussed in the Akademy presentation, the project worked reasonably well. Devices were delivered and the KDE community does see value in the project.

We have reached a point where we understand the value of the initiative and understand the environment much better. We are happy with the results so far and we see room for improvement; both in the task we do to make a better device as well as in defining the product.

Future

I want to see the project moving forward and I will keep working towards better cohesion between hardware vendors and KDE. In the future, I would like to see the devices that we see available, especially when it comes to different use cases, and therefore form factors.

I don’t think it makes sense that we continue doing it just to do so. There is a good deal of hardware vendors that will offer devices with good setups. Most of them they will even offer you these laptops with KDE on them upon demand. If we put our effort in such projects, it needs to be because we are making something special.

Let’s not get ahead of ourselves. One step at a time. Let’s continue to provide good solutions by staying simple by default but powerful when needed.

Snap in Discover and the GNU/Linux Desktop

Last week I attended a sprint with the Snap team and some other members of the community. One of the things we looked into was the Software Center story at depth so I thought it’s a good moment to give you an update.

Discover’s Snap Backend

Long due, some of you have already been using the testing version of it. During this sprint it was refactored to use the snapd-glib library that should simplify a bit the maintainership of this piece of software.
I’m aiming to having a stable snap back-end for Plasma 5.11.

AppStream

One of the reasons holding us back was the lack of AppStream support both in few spaces: getting proper information from the application, leveraging the appstream identifiers. This will allow snap software centers to have rich information ready for users to better choose their software.

My understanding is that the development of these features is well under way and should be available to us soon.

Desktop integration

One of the really cool things about Snap is how well it integrates with cloud/IoT stuff. While this makes it really powerful, us desktop users and developers have seen some things that will need tackling eventually. Things like styling, fonts, icons, etc. need to be properly represented in Snap and it’s good to see this coming together nicely.
These were all subjects that were discussed during the meeting, so do get your hopes high!

KDevelop runtimes: Docker and Flatpak integration

On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s Builder or Qt Creator).

There are different platforms that we’ll be developing for and they need to be easily reachable when coding and testing. Both switching and interacting transparently with the different platforms.

To that end I implemented 4 approaches that integrate different runtimes:

  • Docker, allows you to develop directly against virtually any system. This is especially interesting because it enables to reproduce the environment our users are having: behavior on execution and project information (i.e. the imports are the ones from the target rather the ones on our local system). Docker is a wide-spread technology in the cloud, I hope many developers will see the value in integrating the deployed environment into the IDE while they are coding.
  • Flatpak, is a solution that targets specifically desktop Linux applications. We are talking about distributing bundled applications to users, there we have the opportunity to integrate the tooling specifically to that end: from fetching dependencies to testing on other devices (see videos below).
  • Android, as you know it’s something I’ve been pushing for years. Finally we are getting to a space where the IDE can help get some set up troubles out of the way.
  • The local host, i.e. what we have now.

And remember KDevelop is extensible. Do you want snapcraft?, vagrant?, mock? Contributions are very welcome!

If there’s something better than a list of technologies and buzzwords, that’s videos. Let’s see why this could change how you develop your software.

One development, any platform

We get to develop an application and switch back and forth the target platform we are developing for.

Here I put together a short video that tests Blinken on different platforms:

One development, any device

Using the right SDK is not enough proof that the application will work as expected on every device, especially those our users will be using. Being able to easily send our application to another device to test and play around with is something I had needed for longtime. Especially important when we need to test different form factors or input devices.

In this video we can see how we can easily test an application locally and when it works just switch to Android and send to the device for proper test on the smaller touch screen.

Here we can see how we can just test an application by executing it remotely on another device. This is done by creating a bundle of the application, sending it to the device where we want to test it and executing it there.

Hassle-free contributions

You can’t deny it. You’ve wanted to fix things in the past, but you couldn’t be bothered with setting up the development environment. Both Flatpak and Docker offer the possibility to maintainers to distribute recipes to set up development platforms that can and should be integrated so that we can dedicate this 1 hour in the week-end to fixing that bug that’s been annoying us rather than reading a couple of wikis and – oh, well, never mind, gotta make dinner.

We can do this either by providing the flatpak-builder json manifest (disclaimer: the video is quite slow).

Or a Dockerfile.

You can try this today by building kdevelop git master branch, feedback is welcome. Or wait for KDevelop 5.2 later this year. 🙂

Happy hacking!

Getting Free Software into our users’ hands

In KDE we cover a mix of platforms and form factors that make our technology very powerful. But how to reach so many different systems while maintaining high quality on all of them?

What variables are we talking about?

Form factors

We use different form factors nowadays, daily. When moving, we need to be straight-forward; when focusing we want all functionality.

Together with QtQuick Controls, Kirigami offers ways for us to be flexible both in input types and screen sizes.

Platforms

We are not constantly on the same device, diversity is part of our lives. Recommending our peers the tools we make should always be a possibility, without forcing them into major workflow changes (like changing OS, yes).

Qt has been our tool of choice for years and it’s proven to keep up with the latest industry changes, embracing mobile, and adapting to massively different form factors and operating systems. This integration includes some integration in their look and feel, which is very important to many of us.

Devices & Quality Assurance

We are targeting different devices, we need to allow developers to test and make it easy to reproduce and make the most out of the testing we get, learn from our users.

Whatever is native to the platform. APK (and possibly even Google Play) on Android, Installers on Windows and distribution packages for GNU/Linux.
Furthermore, we’ve been embracing new technologies on GNU/Linux systems that can help a lot in this front including Snap/Flatpak/AppImage, which could help streamline this process as well.

What needs to happen?

Some of these technologies are slowly blooming as they get widely adopted, and our community needs as well to lead in offering tooling and solutions to make all of this viable.

  • We need straightforward quality assurance. We should ensure the conditions under which we develop and test are our users’ platforms. When facing an error, being able to reproduce and test is fundamental.
  • We should allow for swift release cycles. Users should always be on fresh stable releases. When a patch release is submitted, we should test it and then have it available to the users. Nowadays, some users are not benefiting from most stable releases and that’s makes lots of our work in vain.
  • Feedback makes us grow. We need to understand how our applications are being used, if we want to solve the actual problems users are having.

All of this won’t happen automatically. We need people who wants to get their hands dirty and help build the infrastructure to make it happen.

There’s different skills that you can put in practice here: ranging from DevOps, helping to offer fresh quality recipes for your platform of choice, improving testing infrastructure, or actual system development on our development tools and of course any of the upstream projects we use.

Hop on! Help KDE put Free Software on every device!

Discover more in 2017

With 2017 starting, we’re getting ready for the next Plasma 5.9 release and with it a new Discover release.

This will be a special release for two main reasons: further add-ons integration and Kirigami.

New Stuff

One thing pending for a long time was to actually better integrate the different parts of the system that can be integrated. To do so, Discover now will automatically import all knsrc files present on the system and offer them as categories.
We’ll be able to go beyond Plasmoids and Comics (!) and make it possible to explore: Plasma Look and Feel themes, cursors, icon themes, window manager add-ons and different application-specific resources.

This won’t have a big impact on Discover’s performance because the backend code was refactored to be able to have several backends loaded even without knowing all of the resources available. Queries are now asynchronous and parallel.

Discover KNS Addons

Kirigami

Kirigami was adopted in the previous release already, and this release will use Kirigami 2, the port to which did not require much work.

The most significant improvement is the inclusion of keyboard navigation, which was requested by several people and is now finally available. Do you hate it when you’re required to use the mouse? Rejoice!

Extra: Snappy support

It’s 2017, not all of the applications are coming from your distribution anymore. To start getting things in place for different software distribution sources I started working on a Snap backend, which allows us to manage applications coming from this system.
Some work will still be required and it won’t be included by default, since it doesn’t yet support AppStream (although we discussed it and it seems it will happen soon), but if you’re curious feel free to take a look and give your feedback!

GNU/Linux bundled application ramblings

It’s impressive how in the last few months (and especially the last few weeks) the discussion around bundled applications for the GNU/Linux Desktop has sparked.

It’s especially interesting because:

  • The problem is not new.
  • The solutions that have attempted to tackle the problem in the past have been ignored (both by us developers and by distributions).

The TLDR

First, let me try to subjectively summarize the problem: Historically, the resources we get in GNU/Linux come from the distributions. Anything: executables, libraries, icons, wallpapers, etc. There’s been alternatives to all of those, but none has flourished as a globally adopted solution.

This guarantees that everyone using a distribution will have access to the resources the distribution can offer. The more powerful the distribution is, the more we get. There’s limitations nevertheless, so some restrictions have to get in place. The ensemble of limitations and technologies adopted will effectively define the user’s experience.

This works. It has worked for years and, given the technology is in place, it could easily keep working. Like in most engineering solutions there’s drawbacks and properly addressing them can bear some goodness. It seems like now it’s the moment to review this situation. Let’s enumerate some of the problems we have nowadays:

  • We have users using really old versions of our software with issues we’ve solved in versions they can’t use.
  • It’s really hard for GNU/Linux users to get users to test unstable versions of our software.
  • We have users who want to use fresh versions of some software but not in the whole system.

There’s been many solutions to fix those, some easily come to mind: ArchLinux’s AUR (with yaourt), Ubuntu’s PPAs, big-tar application packages, OpenSuse’s OBS, and possibly others.

Far from showing the maturity of the Linux desktop, what this depicts is the deep fragmentation we’re into: we have come up with different solutions that break the established distribution paradigm by lowering the restrictions and considering the resources offered as unsupported (often tainting the whole system).

What has appeared recently is sandboxing. It’s especially interesting because by letting the users execute any binaries we’re increasing the exposition of their systems. Hence, jumping from our distributions’ nest into the lions. As always, sandboxing creates new challenges: It requires changes in applications (or frameworks) to adapt, often creating a user interaction fence (e.g. a popup asking if you let Kamoso access the webcam). For what it’s worth, that’s not new: Android does it, OS X does it, Windows does it (from the Store), Chrome OS does it, etc.

Now where are we?

We need to decide about GNU/Linux’s future. Or at least, we need to understand what Plasma users will have available. So far, most of the noise comes from the big players in the business trying to differentiate their products, meaning incompatible versions.

Without an agreed unified solution, we’ll have to assume we’ll end up having installed snappies, flatpaks, AppImages as well as applications from the distribution. Then it’s just a matter of:

  • Presenting it properly so that the user knows the risks taken by executing an application (!)
  • Make sure we don’t lose many features by sandboxing.

Still, one of the good things of this new approach is that it shouldn’t have to be necessary to have several people dedicated to build every single application and component. If the solution is to add 3 more solutions that will need dedicated people, we’re not really moving forward.

Building

As soon as we’ve decided how we want to work, then the interesting stuff needs to appear. If this is properly engineered, it can bring really interesting possibilities that now we hardly ever find:

  • Newer versions of applications on administered systems (e.g. universities).
  • Enabling stable distributions on professional environments.
  • Beta channels.
  • Binary application 3rd party extensions.
  • Provision of debug symbols (some distros don’t offer them).

To finish the fantastic post, a note for the dreamers:
How easier would all that be in a microkernel architecture?

We need you!

Of course this will be a long journey and we need your collaboration. This year in Randa we started working on all these problems in several different angles. It’s important for the KDE Community to have your support, so we can keep providing quality software. Consider donating, doesn’t need to be a lot, everything counts.

KDE on Flatpak in Randa

I talked about KDE on Flatpak before (called xdg-app then). Lots happened since: new name, fancy new website and a couple of releases shows it’s getting quite stable.

Progress on the KDE side of Flatpak

It’s been some months, and this time has been mostly about maturing what we already had and making it useful for others:

  • Improved the runtime, updates to newer versions of Qt and KDE Frameworks. Some functionality issues were fixed.
  • We published the runtime so that developers can test their applications against it.
  • Added several recipes for KDE Applications (help! testers required).
  • We got some initial documentation for developers.

Next steps

Now it’s time to make this work. I find it already close to magic how we get to compile in one distro and works on another. I must admit, I’m excited. But then many things need work, should be simple, but we need to spend the time.

Also we need to compile the applications, start using them and see where’s the limitations, especially regarding the sandboxing. In the end, we also want to bring KDE applications to our GNU/Linux users who cannot reach our stable releases.

Most of it will happen in Randa, let’s see how far we get!

Join us!

Fundraiser

© 2017 TheBlindCow

Theme by Anders NorenUp ↑