Plasma Meeting: Web, browsers and app bundles

This year’s Plasma Sprint is kindly being hosted by von Affenfels, a software company in Stuttgart, Germany, focusing on mobile apps. Let me try to give you an idea of what we’re working on this week.

Bundled apps

Welcome, KDE hackers!
Welcome, KDE hackers!
One problem we’re facing in KDE is that for Linux, our most important target platform, we depend on Linux distributors to ship our apps and updates for it. This is problematic on the distro side, since the work on packaging has to be duplicated by many different people, but it’s also a problem for application developers, since it may take weeks, months or until forever until an update becomes available for users. This is a serious problem and puts us far, far behind for example deployment cycles for webapps.

Bundled app technologies such as flatpak, appimage and snap solve this problem by allowing us to create one of these packages and deploy them across a wide range of distributions. That means that we could go as far as shipping apps ourselves and cutting out the distros as middle men. This has a bunch of advantages:

  • Releases and fixes can reach the user much quicker as we don’t have to wait for distros with their own cycles, policies and resources to pick up our updates
  • Users can easily get the lastest version of the software they need, without being bound to what the distro ships
  • Packaging and testing effort is vastly reduced as it has to only be done once, and not for every distro out there
  • Distros with less man-power, who may not be able to package and offer a lot of software can make available many more appliations,…
  • …and at the same time concentrate their efforts on the core of their OS

From a Plasma point of view, we want to concentrate on a single technology, and not three of them. My personal favorite is flatpak, as it is technologically the most advanced, it doesn’t rely on a proprietary and centralized server component. Unless Canonical changes the way they control snaps, flatpak should be the technology KDE concentrates on. This hasn’t been formally decided however, and the jury is still out. I think it’s important to realize that KDE isn’t served by adopting a technology for a process as important as software distribution that could be switched off by a single company. This would pose an unacceptable risk, and it would send the wrong signal to the rest of the Free software community.

How would this look like to the user? I can imagine KDE to ship applications directly. We already build our code on pretty much every commit, we are actually the best candidate to know how to build it properly. We’d integrate this seamlessly in Discover through the KDE store, and users should be able to install our applications very easily, perhaps similarly to openSUSE’s one click install, but based on appstream metadata.

Website work

Hackers hacking.
Hackers hacking.

We started off the meeting by going over and categorizing topics and then dove straight into the first topic: Communication and Design. There’s a new website for Plasma (and the whole of KDE) coming, thanks to the tireless work of Ken Vermette. We went over most of his recent work to review and suggest fixes, but also to get a bit excited about this new public face of Plasma. The website is part of a bigger problem: In KDE, we’re doing lots of excellent work, but we fail to communicate it properly, regularly and in ways and media that reach our target audience. In fact, we haven’t even clearly defined the target audience. This is something we want to tackle in the near future as well, so stay tuned.

But also webbrowsers….

KDE Plasma in 2017
KDE Plasma in 2017

Kai Uwe demo’ed his work on better integration of browsers: Native notifications instead of the out-of-place notifications created by the browser, controls for media player integration between Plasma and the browser (so your album artwork gets shown in the panel’s media controller), acccess to tabs, closing all incognito tabs from Plasma, including individual browser and a few more cool features. Plasma already has most of this functionality, so the bigger part of this has to be in the browser. Kai has implemented the browser side of things as an extension for Chromium (that’s what he uses, Firefox support is also planned), and we’re discussing how we can bring this extension to the attention of the users, possibly preinstalling it so you get the improvements in browser integration without having to spend a thought on it.

On and on…

We only just started our sprint, and there are many more things we’re working on and discussing. The above is my account of some things we discussed so far, but I’m planning to keep you posted.

30 thoughts on “Plasma Meeting: Web, browsers and app bundles

  1. Why there is no contest for wallpaper anymore like it was the practice in the late KDE 3 series and in early KDE 4 releases? It would help the community to feel more connected to the project.

  2. I’ll repost here what I wrote on IRC (slightly reworded for clarity):

    This post has got me worried, especially when I see “That means that we could go as far as shipping apps ourselves and cutting out the distros as middle men.” Althrough distributions distribute, it isn’t the only thing they do.

    I urge at least not to think of them as second-class citizens.

    1. Packaging every single app for every distribution is IMO a waste of time. Distro developers would be spending their time more effectively by working on the things that do make a difference. (And I think that’s what you’re meaning with “isn’t the only thing they do”.)

      I’m not suggesting to remove or ignore distros, but for distros to be able to concentrate on the things that matter, rather than creating, maintaining and updating 10.000 application packages.

      1. > Packaging every single app for every distribution is IMO a waste of time.

        That’s why you have build systems that should – technically – do the job for you. (The OBS is a prime example, but not the only one).

        > Distro developers would be spending their time more effectively by working on the things that do make a difference.

        The “things that make a difference” include integration (something neither snaps, nor flatpaks, nor appimages will ever do properly), security reviews (KAuth had a race condition – low impact, to be fair – and that only came out with the openSUSE security review), legal reviews (yes, I still see incompatible licenses mixed up to this day) and QA (openQA on the current state of git master, anyone? It’s being done).

        And out of 10.000 packages, not everything is updated at the same speed. Plasma is one of the faster contenders, but other applications evolve far more slowly. In my experience, a good part of these issues can be solved with automation[1] and with rolling (tested) releases rather than fixed-in-time releases.


        1. These efforts are all totally useful, and it would be awesome if they could be done without repackaging the same software over and over. Arguably, this should be done in closer collaboration with upstream. (The openSUSE team is already doing a really good job, other distros are a bit behind, usually due to manpower problems.)

          OBS is pretty good indeed, but somehow never made good on the promise of being able to deploy to many different distros. Especially Debian package support was sub-par when we looked at it, and people who could potentially work on it, were scared away by the complexity of OBS.

      2. >Packaging every single app for every distribution is IMO a waste of time. Distro >developers would be spending their time more effectively by working on the >things that do make a difference. (And I think that’s what you’re meaning with >“isn’t the only thing they do”.)

        Agreed about the waste of time about packaging everything. However I also think that technologies like flatpak are on the verge of opening an entire new can of worms (increasing complexity always involves more subtle issues)…
        Another question is : “Where do the distributions make a difference?” Init system? Filesystem layout? Utilities to switch between implementations of stuff? Experience from install to desktop?
        For me distributions make a difference in the way they update software. I absolutely hate software that updates itself at some random point. Security updates are ongoing, bigger updates are friday afternoon.

        Since developers apparently want to (understandably) also distribute their software, IMO a better approach would be a “meta” package format, which the the developers maintain for their product in their repository. This “meta” package format already exists, namely the PMS ( Combine this with a multiformat package manager like Paludis (which AFAIK could be expanded to produce deb or rpm or archlinux packages), and you get a toolbox for distributions and upstream to collaborate directly on distributing the software. OBS comes very close to this.

        All this to say : I see where the desire for things like flatpak come from, but I also think it isn’t the right solution…
        And thank you for your work on KDE-stuff.

      3. > Packaging every single app for every distribution is IMO a waste of time.

        IMHO, it is not.

        Application bundles bundle all the libraries with every single application. Flatpak at least allows depending on a “runtime” that has most of the libraries, but the “runtime” still duplicates system libraries, applications can depend on different versions of the “runtime”, leading to duplication, there is also duplication between different “runtimes” (e.g., the Qt/KDE and the GTK+/GNOME one, which surely have several common libraries), and any and all libraries not contained in the “runtime” still have to be bundled. Bundled libraries waste space (download bandwidth, disk space, and even RAM, because shared libraries can be shared even in RAM) and are a nightmare for security updates. Most application bundles I saw also do not honor the copyleft licenses of the bundled libraries. (You have to include complete corresponding source code including packaging scripts for the exact version of every single library that you bundled!)

        Distribution packagers also fix integration issues, both user-visible ones (UI integration) and system-level ones (making things build against the system version of the library so that you don’t have to bundle a different one with every application), backport bugfixes, etc. And a native package will always bring a better user experience than a bundle.

        > Distro developers would be spending their time more effectively by working on the things that do make a difference.

        What would those be? If every distro just redistributes your blobs, there will be no added value to any of them.

  3. Why bothering about “web browser integration”, when all efforts should be orientated to developing a trully KDE web browser? Konqueror has left to its own luck, reKonq died and we have nothing but install a non-KDE (or even a non-Qt) web browser.

    1. I disagree with all “efforts should be orientated to developing a trully KDE web browser”, it’s simply not a feasible thing right now. (And I know what I’m talking about, having gone through this exercise twice in my life.)

    2. Try QupZilla, it is working great for me. It’s a Qt-only application, but it has a KWallet plugin, supports native notifications, uses native file dialogs through Qt, etc. I am using it as my everyday browser at the moment.

      Konqueror is also looking like something to consider again now that it got ported to KF5 and has a KWebEnginePart available (and there’s also a newer QtWebKit that the KWebKitPart should work with), but there are some regressions from the port that need fixing urgently (settings such as the window position are not saved, and the KWebEnginePart does not remember passwords, both are filed on already).

  4. > Althrough distributions distribute, it isn’t the only thing they do. I urge at least not to think of them as second-class citizens.

    I can agree with that but still I’m welcoming the introduction of flatpak. To me this primarily means that I can have the latest version of an application (be it git or just the latest stable release) without waiting for my distro. There are some applications which I track very closely so I want the latest stuff there.

    Then at some point I imagine to switch back to the distro package when it is “good enough” (which is “never” for my top apps but “common” for others e.g. after a bug is fixed). Also I assume it will be much easier for me to send good bug reports if I can easily try (and wipe) the latest released version.

    And last but not least flatpak’s sandboxing abilities are a welcome change. I hope that even the distro-provided applications could be shipped as “flatpak” (via the usual RPM/deb packages) if upstream supports sandboxing.

    So far my personal impression from the kde+gnome developer communities is that nobody targets replacing distributions entirely but flatpak (and maybe snaps) might help to limit some of the pain inflicted by distribution policies (bug reports about really old versions, “just a new version of this app but everything else stable”) and lack of maintainer time.

    That being said it might be that distributions loose interest in packaging some low-profile apps which is likely ok too.

  5. Great News.

    Anything to ensure the distro you are using has the latest software is a good thing.

    People running for example Kubuntu LTS or Opensuse leap are running older versions of Plasma, often with known bugs in that are not going to be fixed in that version.

    Kde-neon is a far better plasma experience than any LTS distro I have used.

    1. > Opensuse leap are running older versions of Plasma, often with known bugs in that are not going to be fixed in that version.

      Leap tracks the LTS version of Plasma. Don’t get fooled by the version number that’s not bumped: all bugfixes end up there in the end.

  6. Please, can you also consider working on multi-monitor support? I know this is mainly something to be done more low-level in kwin etc. But I think this is also a Plasma thing – isn’t it Plasma that stores the setup of the desktop like the position of panels and plasmoids? So it is no more problem to plug in and out a projector or a second monitor.
    That is far more important than cross desktop functionality or webbrowser integration.

    1. I have been spending most of my time in the past year working on multi-monitor support and I do still spend quite some time on a weekly basis on it. As a result, multi-monitor support has improved vastly over the past year. I’m not saying it’s perfect, but it works and works well for the majority of users that have bothered reporting back.

      Do you have specific bugs, or is that a general sentiment? (In the first case, hop over to bugzilla, that’s where we do issue tracking, in the general sentiment’s case, thanks for pointing it out.)

  7. Just a correction on snaps, they are not a Canonical-only technology and in fact the format is designed to be as open as possible – Anyone can take the code (it’s open source) and implement what ever solution they see fit. What I think you are referring to when you say that the technology could be “… switched off by a single company” is the Ubuntu Store where a lot of snaps currently come from. Well, this is one implementation of a store that yes, Canonical does have control over but it is not, and doesn’t have to be, the only store. In fact others have started hosting snaps (see uAppExplorer for example) so to discount the technology on the grounds that Canonical have a snap store is missing the point IMHO.

    Disclaimer: I work for Canonical but these views are my own.

    1. Well, snaps are theoretically open and distro-agnostic, but in really not so much. It’s true that the format doesn’t prevent you from running snaps on other distributions, but the support hasn’t really gotten into many of them, usually resides in 3rd party repositories, often not updated. Flatpak has already made its way to official repositories of Arch, Fedora, Debian, Ubuntu, openSUSE, Mageia,… It’s true that you can build an independent repository of snaps, but you have to build one. Flatpak has supported this option from very beginning. Creating a flatpak repo is as simple as running one command with flatpak-builder and uploading it to a static web server. It’s true that you could build snaps on any distribution, but the reality is that the tooling that is around snaps currently relies on Ubuntu while you can build flatpaks on many distributions without any dependency on them.

      In my opinion, Flatpak is currently much better positioned than snaps to be a distro-agnostic technology for distributing Linux apps. My feeling is that Canonical started snaps as Ubuntu-only thing and then with the emerging competition like Flatpak or AppImage realised they wouldn’t get the whole ecosystem on board if it’s Ubuntu-only, and thus have been trying to make it available on other distributions, too. But it’s far from being ready to be a truly distro-agnostic technology. Not sure if the strategy “the format is open, all the tooling we’ve built around it is for Ubuntu, but hey, you can fully port snapd to your distro, work on snapcraft to run on it, too, create your own alternative to Ubuntu Core, build your own snap distribution solution, and then you won’t depend on Canonical” will work. Why would one do that if there are solutions that give you all this without having to do (almost) anything?

  8. Have you guys looked at Habitat( )?
    Anyone can run a Habitat depot…
    You can have 20 versions of the same application running in parallel without issues while there is maximum dependencies re-use.
    I ran it in a minimal Alpine container and it worked without any issues(I installed gdb with it and it was working nicely).
    It’s a single static binary(Musl) that has 1 single dependency: Linux Kernel 2.6+.

    Here you can see GDB as an example(This is their’s depot, but anybody can set their own):
    On the right you can see all the dependencies listed by specific version, date and even build id. All those versions are the dependencies that this particular build of the package used and will automatically download to make sure all the users get consistent results.

    1. Well, thanks a lot for sharing your experiences

      Habitat is on my list since some days and i love, next to the advantages which you wrote down here, that its written in Rust and founded by a company.

      Does your setup include graphical applications?
      Since one developer wrote to me, that he thinks its only suitable for server applications.

      Thanks a lot

  9. ” Kai has implemented the browser side of things as an extension for Chromium (that’s what he uses, Firefox support is also planned), and we’re discussing how we can bring this extension to the attention of the users”

    Do you have any links or pointers to find out more about this work? I

  10. Would love to see moving forward with flatpak. Its completely distro independent nor brings in extra dependencies unlike snaps and supported in multiple distros

  11. Hi Sebas,

    KDE 5 has grown strong, and feels like a very mature and stable series compared to that of 4.x which many people seemed to complain about stability and inconsistency of the elements in KDE. Perhaps the migration from QGraphicsView to QML complicated matters, but that is all in the past.

    My qualm over the past two-three years, there doesn’t seem to be any grande overall vision, or roadmap for the community and the platform. The only thing I see is the transition towards Wayland, but each release seems incremental improvement, but not leading towards a greater whole – maybe there is but I don’t really see it. This itself is fine as a development model, but I always felt KDE innovated.

    It would be nice to know where KDE is heading in 3-5 years time. KDE 4 had a vision, despite some elements that simply didn’t work out very well in the end. I am not writing to criticise any of the work done – KDE 5 is a solid release and does everything pretty well.

  12. See, i come here to write a long and specific post and see your answer towards Lilian just right now, so thanks a lot, that you reduce my amount of time, which i will invest, by showing the typical blind, arrogant, ignorant and whatsoever attitude, which i am used to see from most developers.

    There are o lot of options on all the fields of open source and of course is each and every single one of that option worth an evaluation test – your comment shows me, that you are interested to force your own views on us, i am sure you can see that now.

    How can i trust someone to package correctly?

    Which is already a task which the mass of the distros do partly blind in specific cases since years, by mixing the new Stack with the old one as a simple example.

    Such things get often support by a lot of KDE coders, who decide to blame their own software while the packaging cause the issues. -.-

    And then they decide in the next breath take to ignore projects, who increase the stability significantly and avoid to run into issues, who happen on all the other distros.

  13. App bundles will make it easier for users to test the latest version of software. In many projects, if I report a bug the immediate response from developers is “Does it happen in the development version?” The answer for most users is …??x!? Pointing moderately experienced users to a nightly flatpak repository seems far easier than getting them to add a PPA, unzip a binary, build from source, or run a docker/VM image.

    Will a flatpak app bundled with the newest KDE Framework cooperate with an older Plasma desktop?

Comments are closed.