Category Archives: Uncategorized

KF6 Sprint in Berlin

BlaBlaSoftware

From the 21st to 24st of Novemember, a bunch of KDE people gathered in Berlin graciously hosted by the MBition offices to discuss about the next big iteration of the KDE frameworks.

Work on Qt6 started, and it will be a big refactor that makes the api quite better, solve some architectural problems in some Qt5 areas (one of my personal favorites is the new QGuiAction class coming out of the split of QAction in a QWidget-less implementation). In order to have that, it needs to be binary incompatible with Qt5 tough.

As it will be incompatible, we need to adapt our software and our frameworks.. a lot of work ahead, but big opportunities as well, so… It’s time for KF6, where we can do the same thing: polish our API and solve some problems we couldn’t do in KF5 in a binary compatible way.

We worked in groups, assisted remotely by David Faure and looked at the frameworks we were less happy and need more a refactor.. The first obvious candidate are those tier 3.

Our fancy Kanban board

The Tier system in frameworks means that frameworks of tier 1 don’t depend from other things than Qt modules and base system libraries. Tier 2 frameworks can also depend from tier 1 frameworks, and tier 3 from tier 2.

In reality there are some tier 3 frameworks which “real” tier would be 5 or 6 as may depend from multiple other tier 3 frameworks. Those of course are the first that need to be looked at. Ideally we should manage to lower the tier of frameworks as much as possible and at least having tier 3 ones that are actually tier 3, and not 4 or 5.

Some typical examples are KIO, KDeclarative, KXmlGui, and Plasma-framework.

For the KDeclarative case, the reason is that its genesis was quite peculiar. When in late KDE4 – early KF5 was starting to be apparent that the focus of the future in GUI programming in Qt was probably going to shift towards QML, we chosen at first to put the bindings to QML of the frameworks we needed in a single umbrella repository, ending up with a git repo full of many tiny QML plugins that depended from one framework or another… ending up with a framework that depended from just about all the others. It will be split out and every useful QML binding will go into the proper framework: as QML is now a super central part of Qt, frameworks need to play well with it to be an important citizen of the Qt ecosystem.

Plasma framework

Now talking about a part that is really near to my hearth: Plasma-framework. It’s a pretty high tier because it depends from KXmlGui and KDeclarative. As we seen, both of those dependencies will be not too hard to remove (famous last words :).

My plan is to have the main plasma library splitted in 3 smaller frameworks, each one tier2 maximum:

  • libplasma: the part that manages load and save of your desktop layout, all that is related of loading a plasmoid and the api that palsmoids will use to interact with the Plasma workspace
  • theming: Plasma uses svg-based themes with significant optimizations like disk-caching of the rendered bits, which support stylesheets for dynamic colors based on your system ones: this should be a framework in itself, usable by any app: probably tier 2
  • dataengines: that’s a technology not much used anymore and is kinda being phased out. Should exist standalone as a “porting aid”

With this, hopefully Plasma will be even leaner, further improving startup time and memory usage, while on the same time applications gains a framework for doing light weight and feature rich svg based graphics theming.

Plasma Edit Mode refinements

GraphicsSoftware

Editing, moving and customizing widgets in Plasma Desktop improved a lot in 5.17, and then in 5.18 it will get a brand new edit mode, to be really efficient editing your desktop layout (and have less visual noise by default).

This week another new feature landed in the edit mode for 5.18: it’s possible to set some plasmoids without background and a nice drop shadow, for an extra clean and modern look for your desktop.

In addition, a plasmoid can specify this backgroundless shadowed mode as its new default, like the digital clock now does (when is on the deskop)

Applet developers will have to opt in this feature: doesn’t always make sense everywhere and some may still be buggy. Some default plasmoids, especially in kdeplasma-addons have been set to support it.

If you are writing a plasmoid and want to support this background removal, in the main QML item of your plasmoid you can do:

Item {
    id: root   
    Plasmoid.backgroundHints: PlasmaCore.Types.DefaultBackground
                             | PlasmaCore.Types.ConfigurableBackground
    ...
}

Or, if you want to default toi the new background-less, automatic shadow:

Item {
    id: root   
    Plasmoid.backgroundHints: PlasmaCore.Types.ShadowBackground
                             | PlasmaCore.Types.ConfigurableBackground
    ...
}

Of course the NoBackground option is still there if a shadow isn’t what the graphic style of the plasmoid needs.

A notice that needs to be kept in mind, is that for color inversion to work automatically, one should never do:

    color: theme.textColor

But rather

    color: PlasmaCore.ColorScope.textColor

Which is a good way to get ready for Qt6 anyways, as context properties are going to be removed in the next Qt major release.

Choose Your Own Experience in Plasma 5.8 and beyond

GraphicsSoftware

One of the key points of Plasma is while giving a simple default desktop experience, not limiting the user to that single, pre-packed one size fits all UI.
Its strength is to be flexible to greatly different user needs, “Simple by default, powerful when needed”.
Several years ago, the Visual Design Group had the idea of making easy to build and share desktop layouts to make easy to test wildly different user interfaces, see this old post by Thomas on the topic.
Since then, work on it has been going on, mostly on the infrastructure needed to make it a reality, and in Plasma 5.8 the first pieces are there, tough still far from the complete experience we want to offer.

The support for Look and Feel packages is there since a while (5.3 or so) that’s what one of those package can do:

  • Provide a default layout for when Plasma starts for the first time, it was used for distributions to personalise their UI, but now is easier for users as well.
  • Provide some default look options, like what color scheme to use, what icon theme etc
  • (advanced) provide the actual implementation of some UI, such as KRunner, the Alt+Tab window switcher dialog, the lock screen

So far the default Plasma layout provided by the Look and Feel theme was used only when starting up for the first time, on a clean user home (therefore very useful for distributions) but sice Plasma 5.8, in the Workspace theme -> Look & Feel section of system settings there is an option to load the new layout when switching the look and feel theme. Not as default as is a destructive action that will remove your current Desktop setup.

desk

The other component is a tiny little application shipped in the “Plasma Sdk” package that’s called lookandfeelexplorer.
lookandfeelexplorer
With this applciation you can:

  • Create a new Look and Feel theme
  • Edit the metadata and thumbnail of a locally created/installed theme
  • Create a default javascript desktop layout based upon your current Plasma setup
  • Create a defaults file based upon your current setup as well, such as color scheme and icon theme

The last two are the central part of sharing your idea of “the perfect desktop” with others, linked with the integration between the Look & Feel systemsetting module and the KDE store, also new in Plasma 5.8.

It’s still a preliminary feature, as ideally in the future if your shared Look & Feel theme depends for instance from a particular icon theme or a particular 3rd party plasmoid, the store integration will download those dependencies as well.

Systemtray, Plasma Next and GTK

BlaBlaSoftware

You may have heard that KDE Plasma Next won’t support anymore the old X11,Xembed-based systemtray icons.
(More information here)

Years ago, we developed a nicer, model/view based alternative in which is the shell that actually draws the systemtray icon, allowing better integration with the workspace, it’s a specification that is now shared between KDE and Ubuntu Unity.
All KDE applications use it already, Qt4/Qt5-only application will use it depending on a small patch (and soon Qt5 will do out of the box)

But also GTK has some options: until today I was aware only about the Ubuntu’s appindicator library, but I have just been contacted by the author of another neat library, that can be found here on GitHub.
It’s a very small, few dependencies GObject-based library that allows a GTK3 application to export and control a statusnotifier-based systemtray icon. I just tested it on KDE4 and Plasma Next and seems to work quite well.
So if you have a GTK application that is using a systemtray icon, and you would like the icon to be integrated in the next version of Plasma as well, now you have an option more (and of course, the author will be happy of any patch/bugreport/bugfix).

KDE on improv, now with videos

I’m finishing the images of the OS that will be shipped by default on the Improv. As soon they are finished they will be available for download, alongside recipes on how to build new ones from scratch.
So at this point, I tought it was a good time to take some videos.
The default os, will be a kind of “tasting plate” for developers, it will be possible to try many combinations of software.
By default it will start with a normal console login, so very fast and ready for “small server” duties.
By going to graphical mode (init 5) it will start the SDDM login manager, from which several sessions will be available:
It will be possible to chose between OpenBox or a full KDE Plasma Desktop or KDE Plasma Active sessions (the latter two being completely independednt saving their settings separately).
Here is a video showing the 3 environments running on the Improv (the little board itself is visible in the bottom right corner of the screen)

Another important thing that is available there is Qt 5 (at the moment 5.1, upgradable in any moment newer packages will land on Mer)
This will give a very convenient development environment for Qt5 and QML2 based applications, to test their performance on a mobile/ARM based device.

Plasma Workspace: present and future

We saw last week the release of the first beta of KDE Plasma Workspace and applications 4.11

From my side, that’s a very important milestone, because it’s pretty much the coronation of what we intended the 4.x series of the workspace to be. It was a long ride, but I think this future release will be pretty stable and “defined” in its own identity.

The 4.11 release of the Workspace will be supported for years to come, marking in fact the last big feature release of the 4.x series.

This sounds pretty scary, but it indicates a lot of maturity, 4.11 will be a release you can count on being maintained abd bugs fixed for a long time. Nice for home users, utterly awesome for bigger deployments.

Just to clarify: this regards only Plasma Workspace so far. Applications will continue feature releases as usual, after all KDE is not a software, is a community that releases a lot of eterogeneous pieces of software.

So, were are now?

  • The desktop shell is useful by default. A default setup has all the typical functionality that a typical desktop usage needs, but.. one size does not fit all.
  • The desktop shell is very flexible, trying to not force a paradigm on you, assemmble it at your liking.
  • We have at least 5 different shells: Desktop, Netbook, Plamsa Active, Media center, part for application dashboards. Because one size does not fit all, on different devices we try to give you the best experience given the particular device.
  • QML: It’s very easy to write new components for your desktop/tablet/mediacenter/whatever with an easy scripting language.

But of course we never are happy: we want to do new things and have new features in the future..

  • We are porting to Qt5 and QML2
  • The whole workspace will be rendered by the GPU: faster and will be possible to have beautiful effects.
  • We will have one shell to rule them all: the actual Plasma Shell becomes just a generic “viewer” with no UI whatsoever by itself. Since all the UI elements will be done by QML, they can be loaded and unloaded, so a different device experience can be dynamically loaded when for instance you plug your tablet to a docking station, the full Desktop shell starts.
  • Even tough it will mean a quite big technology change, since we are quite happy with the overall direction of each one of our shells, there won’t be radical UI changes, except of course the usual incremental upgrades and refinements.

I’ll do a talk about Plasma2 at Akademy, going a bit more in deep about the technology, the big picture concept and how to get involved in, so see you there 🙂

I'm going to Akademy