Plasma Convergence, technically

A Plasma Phone
A Plasma Phone

In one of my latest blogs, I’ve explained what convergence is, how Plasma benefits from it, and why we consider it a goal for Plasma. This time around, I’ll explain the how, how it works across the stack and how we implemented it. Naturally, this article dives a lot deeper, technically, than my previous one.

Convergence plays a role at different levels of the whole software stack. In this, more technical article, I’ll look at different layers of the software stack, from boot/kernel and middleware to UI controls and overall layout and input methods. After reading this article, you’ll understand how Plasma allows to use the same software on a range of devices, which parts are different, and where code sharing makes sense, and thus happens.
Keep in mind that Convergence, at least for Plasma, doesn’t mean that we ship a lowest-common denominator UI so it “kind of” runs on all things computer, but that it provides a toolbox to build customized UIs that allow taking advantage of specific characteristics of a given target device.

Lower Levels and Packaging

Plasma -- same code, different devices
Plasma — same code, different devices

One aspect of convergence that is of course the deployment side. This doesn’t just include the kernel and bootloader, which needs to be compiled differently for ARM devices and for x86 devices. The rest of the stack is by now largely the same. We are now using the same set of packages and CI for both, mobile and desktop builds, in fact most packages are the same, and the difference between a device set up for mobile use cases and desktop is the selection of packages, and what gets started by default. Everything is integrated to a very large degree, lots of work is shared which means timely updates across the device spectrum we serve.

Controls

Plasma Mobile
Plasma Mobile

When it comes to user interface controls, such as buttons, text fields, etc., convergence is mostly a solved problem. Touch input is possible, Qt nowadays even ships a virtual keyboard (which Plasma uses for example for password input in the lock-screen), and buttons react to touch events as well. QtQuick-based user interfaces often work quite well with both, keyboard/mouse and touch input, in fact touch is one of the design goals of QtQuick.

Not everything is perfect yet, however, especially text selection and keyboard control of QtQuick-based UIs often still requires custom-code, meaning it needs more development and maintainance time to get right. QWidget-based UIs are still a bit ahead of the game here, though often the benefits of also being able to deploy an app on touch devices (such as many Android devices out there!) make QtQuick an attractive technology to use. We see more and more QtQuick-based applications, as this technology matures also for desktop use-cases.

Widgets

Convergent Plasma Widgets
Convergent Plasma Widgets

Plasma is made of widgets. Even in a standard Plasma desktop, everything is a widget: The menu in the bottom left is a widget, the task manager is, the system tray is a widget, and there are widgets inside the system tray for notifications, battery, sound, network, etc.. Plasma is widgets.
These widgets can be used on any device of course, but it doesn’t always make sense. Some of these widgets are very specific for desktops. The task-manager (that thing you use to switch windows, which is usually located in center of the bottom panel) doesn’t really make sense on a mobile device. For a mobile device, which needs larger areas to touch, something more aking to a full-screen window switcher is useful (and in fact what we use for Plasma Mobile). Other widgets, such as the network connections widget or battery and brightness widgets are perfectly suitable also for mobile devices. Plasma’s architecture allows us to re-use the components that need no or just little changes and use them across devices. That means we can concentrate on the missing bits for each device, and that in turn means we can deliver a feature-rich and consistent UI across devices much easier, while making sure the specific characteristics of a given form-factor are used to their fullest extent.
Again, by sharing the components that make sense to share, we can deliver higher quality features for a given devices with less effort, and thus quicker.

Shell and Look & Feel

Look & Feel setup for Plasma
Look & Feel setup for Plasma

Plasma can dynamically load different so-called shell packages. The shell package defines the overall layout of the workspace environment. On the desktop, it says that there’s a fullscreen wallpaper background, with a folderview, a panel at the bottom and the widgets which are loaded into that panel: application launcher, task-manager, system tray and clock for example.
The shell package is different for each device, as this defines the overall workflow, which is highly dependent on the type of device.

To take differences between devices even further, Plasma has the concept of “Look and Feel” packages, which allow further specilialization how a device, well, looks and feels. There’s the widget style and the wallpaper of course. The Look and feel package also defines interaction patterns, such as if a settings interface should use “instant apply” when a setting is changed, or if it should present an “Apply and Okay” button for the user to save settings. Mobile devices typically use instant apply, while desktop interfaces (at least Plasma’s) use the “Apply and Okay” concept throughout. For Plasma UIs, this can be changed dynamically. Plasma’s Look and Feel features is not just useful in the convergence aspect, it allows also for example to switch between a traditional default Plasma setup and a workspace that closely resembles Unity. These “Look and Feel” packages are available through the KDE store, so they’re easy to install and share. There’s even a cool tool that allows you to create your own Look and Feel packages, very much like themes.

Apps

Subsurface Mobile, Linux, Android and iOS from the same code-base
Subsurface Mobile, Linux, Android and iOS from the same code-base

Finally, at application level, we see more and more convergent applications. Kirigami, a high-level toolkit that supplied components for consistent, touch- and keyboard/mouse-friendly application nagivation and layout makes it very easy to create applications with responsive UIs that adapt well to screen size and density and that show flexibility in their input methods. This doesn’t just work between Laptops and phones, but also allows to create one app that works equally well on desktops, laptops, phones and tablets.
Kirigami complements Plasma’s convergence feature on application side, and we recommend it for most newly developed apps. With Qt and QtQuick being a viable target for Android devices, it increases the possible target audience by a very large degree. As an example, Subsurface Mobile, an application for scuba divers, uses Kirigami and works on Linux desktops, Android and iOS, all from the same code-base.

Make it happen…

If you like the idea of convergence, why not join KDE and help us work on Plasma? Perhaps you’d love to see Plasma on a mobile phone? In that case, consider backing the crowdfunding campaign for the librem5 so we can build a convergent phone!

Plasma Mobile and Convergence

Convergence, or the ability the serve different form factors from the same code base, is an often discussed concept. Convergence is at the heart of Plasma‘s design philosophy, but what does this actually mean to how apps are developed? What’s in it for the user? Let’s have a look!

Plasma -- same code, different devices
Plasma — same code, different devices

First, let’s have a look at different angles of “Convergence”. It can actually mean different things, and there is overlap between these. Depending on who you ask, convergence could mean any of the following:

  • Being able to plug a monitor, keyboard and mouse into smartphone and use it as a full-fledged desktop replacement
  • Develop an application that works on a phone as well as on a desktop
  • Create different device user interfaces from the same code base

Convergence, in the broadest sense, has been one of the design goals of Plasma when we started creating it. When we work on Plasma, we ultimately expect components to run on a wide variety of target devices, we refer to that concept as the device spectrum.

Alex, one of Plasma’s designers has created a visual concept for a convergent user interface, that gives an impression how a fully convergent Plasma could look like to the user:

Input Methods and Screen Characteristics

Technically, there are a few aspects of convergence, the most important being: input methods, for example mouse, keyboard, touchscreens or combinations of those, and screen size (both physical dimensions, portrait vs. landscape layout and pixel density).

Touchscreen support is one aspect when it comes to run KDE software on a mobile device or within Plasma Mobile. Touchscreens are not specific to phones any more however, so making an app, or a Plasma component ready for touchscreen usage also benefits people who run Plasma on their convertible laptops, for example. Another big factor is that the app needs to work well on the screen of a smartphone, this means support for high dpi screens as well as a layout that presents the necessary controls in a way that is functional, attractive and user-friendly. With the Kirigami toolkit, which builds on top of QtQuick, we develop apps that work well on both target devices. From a more general point of view, KDE has always developed apps in a cross- platform way, so portability to other platforms is very much at the heart of our codebase.

The Kirigami toolkit, which offers a set of high-level application flow-controls for QtQuick applications achieves exactly that: it allows to built responsive apps that adapt to screen characteristics and input method.

(As an aside, there’s the case for Kirigami also supporting Android. Developing an app specifically for usage in Plasma may be easier, but it is also limiting its reach. Imagine an app running fine on your laptop, but also on your smartphone, be it Android or drive by Plasma Mobile (in the future). That would totally rock, and it would mean a target audience in the billions, not millions. Conversely, providing the technology to create such apps decreases the relative investment compared to the target audience, making technologies such as QtQuick and Kirigami an excellent choice for developers that want to maximize their target audience.)

Plasma Mobile vs. Plasma Desktop

Plasma Mobile is being developed in tandem with the popular Plasma desktop, in fact it shares more then 90% of the code with it. This means that work done on either of the two, mobile and desktop often benefits the other, and that there’s a large degree of compatibility between the two. The result is a system that feels the same across different devices, but makes use of the special capabilities of a given device, and supports different ways of using the software. On the development side, this means huge gains in terms of productivity and quality: A wider set of usage scenarios and having the code running on more machines means that it gets more real-world testing and bugs get shaken out quicker.

Who cares, anyway?

Whether or not convergence is something that users want, I think so. It takes a learning curve for users, and I think advancements in technology to bring this to the market, you need rather powerful hardware, the right connectors, and the right hardware components, so it’s not an easy end-goal. The path to convergence already bears huge benefits, as it means more efficient development, more consistency across different form factors and higher quality code.

Whether or not users care is only relevant to a certain point. Arguably, the biggest benefit of convergence lies in the efficiency of the development process, especially when multiple devices are involved. It doesn’t actually matter all that much if users are going to plug their mouse and keyboard into a phone and use it as a desktop device. Already today, users expect touchscreen to just work, even on laptops, users already expect the convertible being usable when the keyboard is flipped away or unplugged, users already expect to plug a 4K into their 1024×768 resolution laptop and the UI neither becoming unreadable or comically large.

In short: There really is no way around a large degree of convergence in Plasma (and similar products).

Software from the Source

In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community, have better supported software on users systems and allow for better quality at the same time.

Where we are going
Where we are going
In today’s Linux and Free software ecosystems, users usually receive all their software from one source. It usually means that software is well integrated with the system, can be tested in combination with each other and support comes from a single vendor. Compared to systems, in which single software packages are downloaded from their individual vendors and then installed manually, this has huge advantages, as it makes it easy to get updates for everything installed on your system with a single command. The base system and the software comes from the same hands and can be tested as a whole. This ease of upgrading is almost mind-boggling to people who are used to a Windows world, where you’d download 20 .exe installer files post-OS-install and have to update them individually, a hugely time-consuming process and at time outright dangerous as software easily gets out of date.

Traditional model of software deployment
Traditional model of software deployment
There are also downsides to how we handle software deployment and installation currently, most of them revolve around update cycles. There is always a middle man who decides when and what to upgrade. This results in applications getting out of date, which is bad in reality and leads to a number of problems, as security and bug fixes are not making it to users in a timely fashion,

  • It’s not unusual that software installed on a “supported” Linux system is outdated and not at all supported upstream anymore on the day it reaches the user. Worse, policies employed by distributions (or more generally, operating system vendors) will prevent some software packages from ever getting an update other than the most critical security fix within the whole support cycle.
  • Software out in the wild with its problems isn’t supported upstream, bug reports reaching the upstream developers are often invalid and have been fixed in newer versions, or users are asked to test the latest version, which most of the time isn’t available for their OS — this makes it harder to address problems with the software and it’s frustrating for both, users and developers.
  • Even if bugs are fixed in a timely fashion, the likelihood of users of traditional distributions actually receiving these updates without manually installing them is small, especially if users are not aware of it.
  • Packaging software for a variety of different distributions is a huge waste of time. While this can be automated to some extent, it’s still less than ideal as work is duplicated, packaging bugs do happen simply because distribution packagers do not fully understand how a specific piece of software is built and best deployed (there’s a wide variety of software after all) and software stacks aren’t often well-aligned. (More on that later!)
  • Support cycles differ, leading to two problems:
  • Distros need to guarantee support for software they didn’t produce
  • Developers are not sure how much value there is in shipping a release and subsequent bugfix releases, since it takes usually at least months until many users upgrade their OS and receive the new version.
  • Related to that, it can take a long time until a user confirms a bug fix.
  • There is only a small number of distributions who can package every single piece of useful software available. This essentially limits the user’s choice because his niche distro of choice may simply not have all needed software available.

The value of downstreams

One argument that has been made is that downstreams do important work, too. An example for that legal or licensing problems are often found during reviews at SUSE, one of KDE’s downstream partners. These are often fed back to KDE’s developers where the problems can be fixed and be made part of upstream. This doesn’t have to change at all, in fact, with a quicker deployment process, we’re actually able to ship these fixes quicker to users. Likewise, QA that currently happens downstream should actually shift more to upstream so fixes get integrated and deployed quicker.

One big problem that we are currently facing is the variety of software stacks our downstreams use. An example that often bites us is that Linux distributions are combining applications with different versions of Qt. This is not only problematic on desktop form-factors, but has been a significant problem on mobile as well. Running an application against the same version of Qt that developers developed or tested it against means fewer bugs due to a smaller matrix of software stacks, resulting in less user-visible bugs.

In short: We’d be better off if work happening downstream happens more upstream, anyway.

Upstream as software distributor

Software directly from its source
Software directly from its source
So, what’s the idea? Let me explain what I have in mind. This is a bit of a radical idea, but given my above train of thoughts, it may well solve a whole range of problems that I’ve explained.

Linux distributors supply a base system, but most of the UI layers, so the user-visible parts come from downstream KDE (or other vendors, but let’s assume KDE for now). The user gets to run a stable base that boots a system that supports all his hardware and gets updated according to the user’s flavor, but the apps and relevant libraries come from upstream KDE, are maintained, tested and deployed from there. For many of the applications, the middle-man is cut out.

This leads to

  • vastly reduced packaging efforts of distros as apps are only packaged once, not once per distro.
  • much, much shorter delays until a bug fix reaches the user
  • stacks that are carefully put together by those that know the apps’ requirements best

Granted, for a large part of the user’s system that stays relatively static, the current way of using packaged software works just fine. What I’m talking about are the bits and pieces that the users relies on for her productivity, the apps that are fast moving, where fixes are more critical to the user’s productivity, or simply where the user wants to stay more up to date.

Containerization allows systemic improvements

In practice, this can be done by making containerized applications more easily available to the users. Discover, Plasma’s software center, can allow the user to install software directly supplied by KDE and allow to keep it up to date. Users can pick where to get software from, but distros can make smart choices for users as well. Leaner distros could even entirely rely on KDE (or other upstreams) shipping applications and fully concentrate on the base system and advancing that part.

Luckily, containerization technologies now allow us to rethink how we supply users with our software and provide opportunities to let native apps on Linux systems catch up with much shorter deployment cycles and less variety in the stack, resulting in higher quality software on our users’ systems.

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.

Plasma’s road ahead

My Plasma Desktop in 2016
My Plasma Desktop in 2016
On Monday, KDE’s Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?

Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.

With these big words out there, let’s have a look at some specifics we talked about.

Release schedule until 2018

Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:

  • Plasma 5.9: 31 January 2017
  • Plasma 5.10: May 2017
  • Plasma 5.11: September 2017
  • Plasma 5.12: December 2017
  • Plasma 5.13: April 2018
  • Plasma 5.14 LTS: August 2018

A cautionary note, we can’t know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt’s release schedule. Here’s what we intend to do, it is really our “best guess”. Still, this aligns with Qt’s plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?

Breeze Look and Feel

Breeze Look and Feel

UI and Theming

The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.

Feature back-log

The menu button is a first sign of the global menu returning to Plasma
The menu button is a first sign of the global menu returning to Plasma
One thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app’s window (for example at the top of the screen). We’re currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.

Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.

Wayland

The next releases overall will bring further improvements to our Wayland session. Currently, Plasma’s KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn’t seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma’s Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there’s some upstream bug-fixing needed, as well.

One thing we’d like to see to improve our users’ experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it’s tested, it will contain bugs.)

Mobile

Plasma’s Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack’s footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.

Plasma Discover
Discover, Plasma’s software center integrates online content from the KDE Store, its convergent user-interface is provided by the Kirigami framework

Online Services

Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma’s feature-set.

Developer Recruitment

We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.

LTS releases align neatly for Plasma 5.8

Our upcoming release, Plasma 5.8 will be the first long-term supported (LTS) release of the Plasma 5 series. One great thing of this release is that it aligns support time-frames across the whole stack from the desktop through Qt and underlying operating systems. This makes Plasma 5.8 very attractive for users need to that rely on the stability of their computers.

Qt, Frameworks & Plasma

In the middle layer of the software stack, i.e. Qt, KDE Frameworks and Plasma, the support time-frames and conditions roughly look like this:

Qt 5.6

Qt 5.6 has been released in March as the first LTS release in the Qt 5 series. It comes with a 3-year long-term support guarantee, meaning it will receive patch releases providing bug fixes and security updates.

Frameworks 5.26

In tune with Plasma, during the recent Akademy we have decided to make KDE Frameworks, the libraries that underlie Plasma and many KDE applications 18 months of security support and fixes for major bugs, for example crashes. These updates will be shipped as needed for single frameworks and also appear as tags in the git repositories.

Plasma 5.8

The core of our long-term support promise is that Plasma 5.8 will receive at least 18 months of bugfix and security support from upstream KDE. Patch releases with bugfix, security and translation updates will be shipped in fibonacci rhythm.
To make this LTS extra reliable, we’ve concentrated the (still ongoing) development cycle for Plasma 5.8 on stability, bugfixes, performance improvements and overall polish. We want this to shine.
There’s one caveat, however: Wayland support excluded from long-term-support promises, as it is too experimental. X11 as display server is fully supported, of course.

Neon and Distros

You can enjoy these LTS releases from the source through a Neon flavor that ships an updated LTS stack based on Ubuntu’s 16.04 LTS version. openSuse Leap, which focuses on stability and continuity also ships Plasma 5.8, making it a perfect match.
The Plasma team encourages other distros to do the same.

Post LTS

After the 5.8 release, and during its support cycle, KDE will continue to release feature updates for Plasma which are supported through the next development cycle as usual.
Lars Knoll’s Qt roadmap talk (skip to 29:25 if you’re impatient and want to miss an otherwise exciting talk) proposes another Qt LTS release around 2018, which may serve as a base for future planning in the same direction.

It definitely makes a lot of sense to align support time-frames for releases vertically across the stack. This makes support for distributions considerably easier, creates a clearer base for planning for users (both private and institutional) and effectively leads to less headaches in daily life.

Announcing the KDE Software Store

KDE Store
KDE Store
Big news: Today, KDE announced a new software store, and that the source code for this new service has been released as Free software under the AGPL, fixing a long standing bug in KDE software: reliance on a proprietary web service.

That also means that KDE has a new software store that replaces the opendesktop sites. The migration has been happening in the background, so you may actually have used the new store from within Plasma or applications to install add-ons already without noticing it!

We have great plans for the store, one of them being that we want to offer download (and easy installation) of binary packages through containerized bundled formats such as Flatpak, Snappy and/or AppImage.

Stay tuned for more, for now, please celebrate with us a Plasma desktop (and KDE applications) that are more Free than ever before.

Update: I’ve uploaded slides, and there’s a video of my presentation online now.

Plasma at QtCon

QtCon opening keynote
QtCon opening keynote

QtCon 2016 is a special event: it co-hosts KDE’s Akademy, the Qt Contributor summit, the FSFE summit, the VideoLan dev days and KDAB’s training day into one big conference. As such, the conference is buzzing with developers and Free software people (often both traits combined in one person).

Naturally, the Plasma team is there with agenda’s filled to the brim: We want to tell more people about what Plasma has to offer, answer their questions, listen to their feedback and rope them in to work with us on Plasma. We have also planned a bunch of sessions to discuss important topics, let me give some examples:

  • Release Schedule — Our current schedule was based on the needs of a freshly released “dot oh” version (Plasma 5.0), Plasma 5 is now way more mature. Do we want to adjust our release schedule of 4 major versions a year to that?
  • Convergence — How can we improve integration of touch-friendly UIs in our workflows?
  • What are our biggest quality problems right now, and what are we going to do about it?
  • How do we make Plasma Mobile available on more devices, what are our next milestones?
  • How can we improve the Plasma session start?
  • What’s left to make Plasma on Wayland ready for prime-time?
  • How can we improve performance further?
  • etc.

You see, we’re going to be really busy here. You won’t see results of this next week, but this kind of meeting is important to flesh out our development for the next months and years.

All good
All good? – All good!

facelift

I’ve done a facelift to my website. The new version is more mobile-friendly, modern-looking and quite a departure visually from its original look. I’ve chosen for a newpaper-like, typography-based responsive layout. My site finally also supports SSL, thanks to let’s encrypt.

Going to Akademy
Next week, I’ll be going to Akademy, which is co-hosted with QtCon. As usual, my focus will be around Plasma-related topics. I’ll also hold a presentation about a KDE software store.