Category Archives: GNU/Linux

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 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).


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.


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!