Author Archives: Marco Martin

There is a Blur in my Wayland

Over the last few days I decided to help Martin a bit with the ongoing effort on Wayland, since there are still many parts of work missing in order to have a full Plasma Wayland session to just work, but it’s impressive how fast it’s getting there.
It was just a tiny part but is worth sharing it as it brings pretty pictures! (and shows how easy is to contribute).
The popups of the plasma shell need custom positioning code as normal applications can’t position themselves anymore for security reasons, plus KWin uses its effects framework to do a couple of things on plasma panels and popups:

Shadows: the shadows are rendered by KWin, they aren’t really a part of the window, as the shadow must not count anything in the position and resizing phase, but just a visual effect on it, it’s also more semantically correct.
Background effects: both the panel and the popups have a blurred background plus a contrast/saturation effect, to make it more readable and prettier.

After hooking a protocol to control such effects into wayland, here’s the result, almost undistinguishable (there is still a pretty visible graphical issue, points for finding it) from your current X11 Plasma 5.4 session:

So, what needed to be done?

KWayland protocols: each KWin effect that can now be controlled with X properties need its own wayland protocol extension in order to achieve the same thing, I wrote one for blur behind and background contrast (shadow was already there). The good news here is that Martin is working on a tool to auto generate the binding code from the XML specification of the protocol.
KWayland-integration repo: The effects that had KWndowSystem API to control them, need a Wayland implementation as well, this goes in the KWindowSystem wayland plugin contained in the kwayland-integration.git repo.
Modify the KWin effect: then the kwin effect needs to read the data that the client wrote on the surface with the new kwayland protocol and control the effect, in a way that is behaviorally identical to the X11 way, that came from reading X properties from the window

As an “user” of the infrastructure, I’m very impressed about the work that went in the Wayland port of KWin and from the KWayland framework: it really makes using a very challenging and “peculiar” plain C API very easy and elegant in a way familiar with our cozy C++/Qt world.
I can say that is a learning curve soft enough for everyone to jump in and help the big scary transition if they feel to.

Plasma Theme Explorer

In a while, together Plasma 5.3 will be released (independently) a new package: plasma-sdk, containing some very useful tools for development around plasma, some old KDE4 era ones will return, some are new.

plasmate: lightweight IDE for plasmoids (experimental port to KF5, work in progress)
plasmoidviewer: useful to test a single plasmoid, in different formfactors (like desktop, panel, and so on)
plasmaengineexplorer: test and debug tool for dataengines.
cuttlefish: tool for exploring icon themes
plasmathemeexplorer: tool used to explore Plasma themes, let’s talk about this one.

Plasma theme explorer is a new tool that is targeted at designers of Plasma themes.
It can open any installed theme and preview it as a grid of thumbnails of the actual elements rendered.
The thumbnails all have a green or a red dot in it. The ones with a green dot mean that the theme directly provides that element, red means the theme doesn’t have it, so it will fallback to the default theme (currently Breeze). So it makes it very easy and fast to assess the completeness of a theme and to decide what elements to do in order to make the theme more complete.

A sidebar on the right will show a bigger preview of the theme element, together a short description of what the element is for, and an edit button (enabled only for themes installed locally in the user home).

Clicking the edit button, will open the SVG of the theme in inkscape, and will run a little sanitizing script on the file after inkscape is closed.
If the theme doesn’t provide the particular element (and we have a red dot in the thumbnail) the corresponding file from Breeze will be copied in your theme folder, and that one will then be opened in inkscape, making the job of completing a theme easier and faster.

Writing QML based apps, the KDE way

This is an interesting transitional period in the Qt world for desktop applications. We are in the phase where QML is becoming better and better for the use in a Desktop context, even for full fledged applications.
We noticed that there were some bits derived from the many years of experience in Plasma that can be very useful for every application developer out there, that fall pretty much in those categories:

where to install and how to access QML files.
integrating KDE pieces, such as the translation system
how to write an application that is 100% QML and how to distribute it
how to write an application that is a mix between C++ and QML
how to write a KCM for systemsettings that is purely based on qml (and doesn’t even link to QWidgets)

KPackage

Years ago, with the need of having plasmoids implemented with scripted language, we had also the need of having a simple way to distribute those plasmoids around. They are in the end just a bunch of files, that can beany kind of data: the actual source code of the scripts or any needed data assets such as graphics and sounds.
This brought the class Plasma::Package in libplasma, that’s the way to both install/unistall the plasmoid and access any data file or script file from plasmoids.
The problem then posed itself almost identical for things like scripting support in any generic Qt application, like any pack of addons, such as graphics or souds themes.
Same thing for applications based upon QML, that ends up being composed by two parts: purely C++ parts with the central logic and the QML files together any asset that may be needed.
One interesting feature is also that the same files (QML, assets or whatnot) can have versions specific for a particular device, for instance an application may have 99% of the same code between the normal desktop version and one optimized for touchscreen, intended at tablets. Just the few, interested QML files would be duplicated between the desktop and tablet versions.
Since Frameworks 5.6, there is a new tier 2 framework: KPackage, that offers what Plasma::Package offered in libplasma, but with less dependencies and usable by any Qt application that can use a tier 2 framework.

KDeclarative

KDeclarative is the KF5 center for all things related to extending QML.
The framework provides several qml import plugins, such as imports specific of a particular KDE Framework.
It also offers two C++ libraries: libkdeclarative and libquickaddons.
libkdeclarative focuses on KDE related functionalities of the QML engine:

KDeclarative: installs things in the QML engine: such as a KIO-based networkaccessmanager and the 18n() transpations functions.
QmlObject: A class similar to QQuickView: in which you can just set the url of a QML file or a KPackage instance and it loads it, instances the QQmlEngine etc. The difference with QQuickView is that it’s not graphics based and is not a QWindow, you’ll just have the instantiated QObject *. Useful if your project is not graphic or if you already have a view, and you just want to instantiate a new thing for reparenting it into the view you have.
ConfigPropertyMap: it’s a way to access KConfigXT with QML: given a KCoreConfigSkeleton instance, you’ll be abe to read and write its config keys just like it’s a JavaScript Object.

The other one is libquickaddons that focuses on utilities related to QtQuick, the actual graphical components.

ManagedTextureNode: it’s a QSGSimpleTextureNode that will manage its own texture, making simpler to implement your own QQuickItem.
ImageTexturesCache: helps to manage textures by creating images and reference counts them, use it if your QQuickItem starts from QImage.
KQuickAddons::ConfigModule: the base to do KControlModules based on QML, without dependencies from QWidgets, more on that later :).

QML based applications: QML only

qmlpackagelauncher is a tiny command line tool provided by KDeclarative: it’s used to launch an application that is written in QML-only (no main application executable).
The application QML is intended to be distributed in a KPackage structure, with the QML engine initialized with KDeclarative, therefore having things like the i18n() functions available.

QML based applications: mix of QML and C++

The QmlObject class of KDeclarative can now load files from a KPackage, either by setting an existing KPackage instance to it or just setting the kpackage plugin name, making very simple to load a qml file from a plasmoid-like KPackage structure installed on the disk, such as in you main:

KDeclarative::QmlObject *qmlObj = new KDeclarative::QmlObject;
qmlObj->loadPackage("org.kde.example");

For a full application is recomended to use the component ApplicationWindow from QtQuickControls, that’s its own QWindow, so it’s not even necessary to create a QQuickView or QQuickWindow, having the really needed C++ part really just those two lines.

QML based KControlModules

An important part for the ongoing redesign of the Plasma Desktop by the VDG also passes trough writing (and rewriting) modules for Systemsettings or KInfoCenter in QML, to make easy making those franly often outdated UIs beautiful.
One important thing for a mass-migration like that,
ConfigModule has the same API as the old base for kcontrol modules, KCModule, but is a pure QObject, making possible for a future QML-only Systemsettings version.
Start with your old KCModule subclass, keep all the logic in it, but start to scrape off all the QWidget based UI bits and give the class a nice property-based, QML friendly API to read and set the values that will eventually go into the config files.
The actual load and save from the config file, will be done just as in KCModule, by reimplementing ConfigModule::load() and ConfigModule::save().
The UI, QML based part will be provided by a KPackage, with the same name as the component name of the KaboutData of the ConfigModule instance. The QML part will be able to access the configModule instance as the “kcm” global object, just as “plasmoid” is accessible from within the QML code of plasmoids, as well as the ConfigModule QML attached property.

Getting things back: Comics

After the system monitor, today another neat little toy that was gone in the KF5 port returned in Plasma for 5.3: The comic applet.

One thing that I really felt missing for the desktop to be really completed, is an XKCD always on the desktop: how can you live without an XKCD comic always there? I certainly couldn’t 😉
It’s a pretty much straightforward port of the Plasma 4 version: the UI is identical and all options are still where you left them.
I’m pretty happy how it is and how it behaves right now, so personally I consider it in bug fix mode. However, if someone has big ideas on it (and wants to execute them) that would be awesome as well.
The neat thing is that since all the comic plugins were written in JavaScript, all the old ones that can still be downloaded with Get Hot New Stuff still just work(tm).

Getting things back: System Monitor

In Plasma 5.3 some of the things that were lost along the way of the port to Plasma 5 due to the massive architecture change will be back.
Today just got back the system monitor widgets, that helps keeping an eye on the CPU load, disk usage, network traffic and so on.

Along the widgets, a nice reusable component to plot graphs is available to use:


import org.kde.kquickcontrolsaddons 2.0 as KQuickAddons
KQuickAddons.Plotter {
    id: plotter
    dataSets: [
        KQuickAddons.PlotData {
            color: firstcolor
        },
        KQuickAddons.PlotData {
            color: othercolor
        }
    ]
}

Then, (this will vary depending how your data source is implemented) every time a new data set will arrive, you can just do


plotter.addSample([value1, value2]);

You can have as many graphs painted together in the same plotter, depending how many KQuickAddons.PlotData you declare inside the dataSets property.

Yet another way to make your app support StatusNotifierItem

Yesterday I was notified of this little neat project:
github.com/encharm/libsystemtray
(And yes its author would be very happy about feedback patches and so on 😉

Basically it’s a pure C++ library with very few dependencies that implements the support for StatusNotifierItem enabling systemtray icons in KDE Plasma 5 and Ubuntu Unity.
recomonded to be used by C++ applications that don’t actually depend from Qt or GTK and want to keep their dependency footprint very small (it’s Mit licensed so should be ok to use it from an app based on any license)
So now there are officially no excuse to not use our new shiny system tray 😉

Whops I didn’t mean to delete that

This is a little sneak peek of a new feature that will arrive in Plasma 5.2 (OK, to be pedantic since frameworks has a separate schedule, you will be able to get it already next frameworks release a bit before Plasma’s)
Ever ended up deleting a desktop widget, panel widget or even an entire panel just to wish you hadn’t?
One solution may be littering everything with confirmation dialogs, but this quickly becomes annoying, besides the user becoming quickly trained to click “yes” without ever thinking about (I fallen too many times at this kind of dialogs).
So, what can be a better solution? Undo!

When the user deletes something, a notification pops up, notifying that an important thing has been deleted: it offers an action to undo the deletion.
If you click “undo” the widget or panel will instantly come back, if you manually close the notification, it will be irrevocably deleted.

Choose your Look and Feel experience

Plasma 5.1 will make way easier to fine-tune their workspace to their needs.While already very powerful, it was not always trivial, so now on one hand it will be possible choose between plasmoids that offer the same feature with a very simple UI.
On the other hand, ever wanted to set themes, look and feel of your desktop, but was discouraged by how many places you had to change themes to make the experience as you wanted? being icon theme, widget style, plasma theme, cursors etc…
Plasma 5.1 will support the concept of Look and Feel packages (or “mega themes” if you like) Basically an one stop place to set the look and feel of the whole desktop.

To start, there will be a “Breeze” and an “Oxygen” experience, and in the future, let’s hope yours too 😉

In the first release it will be very basic, but in the future it will grow more complete, allowing to more fine-tune individual components, downloading new “look and feels” from the internet etc.

Technically, Look And Feel themes are plasma packages, that contain two things: configuration files for defaults such as icons, colors, cursors etc
and QML files for certain parts of the workspace ui, such as the splashscreen, the lockscreen etc, allowing from very simple things (like a theme that just sets icon theme, widget style etc) to very comprehensive ones, that change completely the logout dialog, lockscreen etc.

On Plasma5: present and future

This is the second part of my ramblings about the Plasma 5 release, just after it come out.

This is a very important moment, after a massive amount of work.

What are the most important things that can make a free software project successful or not?
To me are principally two: user experience and developer experience.

User experience

The first release of Plasma 5 will start to make use of the work of a newly formed group in the KDE community: the Visual Design Group.
I’m very impressed how they managed to get a firm grip of many issues that are always been a problem in KDE software.
They are not only doing nice pictures, but rather starting to give real guidance to the design direction of the future Plasma and applications by KDE.
On the 5.0 release, the most visible thing will be the Breeze theme, that while still far to the final vision, it starts to show the clean and functional style (funny trivia: I remember discussing on the VDG forum about pure flat design versus using 3D effects for “interactive” controls, to give depth and intuitiveness for interactive areas… months before Material was presented. Those guys are definitely onto something.)

But it of course doesn’t stop to a theme and some icons:
what is more deep and a long term plan is to review the look, refinement and usability of pretty much.. everything.
Good design means also every single application has a clean and functional layout, and its “interaction flow” is logic, intuitive and derived from user needs rather than the technical details of the application.
An example of those things still to come is the new layout of System Settings that will come in little piece by piece, one by one in the future releases (The 5.0 release already has a new categorization, each release will move it a step more towards the final design).

Freedom, in all aspects

A big challenge in the design of Plasma 5 is that while providing a very simple and appealing experience out of the box, our central value is to put our priority in serving the different exigences of different kinds of users, because, as for devices, one size does not fit all.

The Plasma workspace is now even more flexible, on different devices it will sport completely different default user interfaces, because different use cases and different input methods require a different way to interact and a different way to present information (as lately even Microsoft discovered, in the very hard way).

And not only that, on your desktop or laptop, you can “build” a workspace experience as you please, optimized to your preferences.
We will never force you to a panel in a particular side of the screen, or to one task manager mode (taskbar vs dock) or to a particular desktop layout.
We well know that this makes the design process more difficult, but often the “easy” solutions are not necessarily the “correct” ones.
We give you a desktop that can adapt to you, rather than giving you a desktop you have to adapt to.

Developer experience

In later years, with the bigger emphasis on the user experience, the experience for developers started to take the back seat.
But we are a free software project, and its success is measured not only in users, but also in how many people would want to engage in an active way, and how comfortable are developers to work on the projects.
Being built on a foundation as strong as Qt, the software by KDE can also offer amazing tools for developers.
The recently released KDE Frameworks 5 is an important step in this direction: the KDE libraries are not anymore a big monolith but a set of very small, useful and independent libraries.

The base of the Plasma Shell is a framework as well: the Plasma framework, composed principally by two things:

The Plasma library: is the good old libplasma.. but it’s way slimmer and more focused than the KDE4 version: It doesn’t offer graphical widgets anymore, and doesn’t make any assumption on what graphic engine will be used (One could even build a shell completely based upon QWidgets with it, just because :p).
It continue to provide easy access to packages, dataengines, asynchronous services and the save and restore functionalities of the layout, known as the Corona.
The library solves problems that are out of scope for QML: from a surface with interactive graphical elements in it, it brings it to a “full featured desktop shell”.
The second part is instead a set of runtime components, of QML bindings that offer QML access to the Plasma facilities such as dataengines and svg themes and a set of graphical components to use in QML plasmoids and applications, such as buttons and text fields, that are converging, and will converge more and more with the upstream QtControls project.
In future releases there will be a comeback of the kpart to easily include qml-based informational dashboards into applications, and a runtime to launch plasmoids as simple independent mini applications.

Looking at the future

So, what are we planning for the future?

The stable, default core Desktop project will become more and more stable and polished, but the development focus will touch other use cases as well.
The Plasma Active port to Frameworks 5 is ongoing, as well the Plasma Mediacenter port, so the “different shell for different devices” story will be complete.
Of course our focus is not only about KDE on different devices, but also making KDE work tightly integrated with other kind of devices, thanks to projects such as KDE Connect. Interestingly, The Plasma Workspace 4.x series is today the environment with the tighter integration with smartphones (only with the next releases of their operating systems Apple is catching up, with a quite similar feature set).
You can expect this integration work being even more complete in future releases of Plasma 5.

Finally, the artwork presented in 5.0 is only a preview of what is still to come from the Visual Design Group: more icons, more complete widget set, more and more applications will receive a makeover look-wise and most importantly usability-wise.

On Plasma 5

We are very, very near the release of the new Plasma release by KDE (more on the nomenclature later).
This is the first entry of a short series of blogs that take a look about the past and the future of Plasma, what we learned from the 4.x series, what changed, what we can take away and to expect for the future.

First, we were (and we still are) very happy about the status of the Plasma desktop as seen in KDE 4.x, but this doesn’t stop to wonder what can be improved.
The Plasma Desktop started to migrate towards QML since quite some time, but it was clear that the real focus in Qt 5.x would have been QML2.
That’s awesome, because QML2 solves many limitation in performance that QML1 and the QGraphicsView framework had in Qt 4.x.
But that was also a problem, since Plasma1 was tightly coupled with QGraphicsView, this meant: a lot of work ahead.
What we wanted, was the plasma platform itself completely independent from any graphical system itself.
From a big monolith-that-provides-everything, libplasma would have become a way smaller library (roughly 1/3 of the code of the plasma library in 4,x), providing a *model* for the layout, and utils as painting utils and the usual data access, but the representation of this model, would have been completely up to the shell (more on that next entry).

I remember starting a branch of libplasma back in summer 2011 at the Berlin desktop summit (that was also when the Frameworks development seriously started to seriously gain steam). The thing lived as mostly a proof of concept for a while.
Fast forward at the end of 2012 and we had a minimal shell that started correctly and could correctly restore a layout of applets, in a minimal desktop (no panel yet!).
The work proceeded and the features got back one by one.
In the meantime many new people joined the effort (Some thanks to Blue Systems, some volunteer) significantly speeding up the process.
Fast forward to the beginning of 2014 and it was possible again to use it as a basic main desktop (eat your own dogfood).
Just to give a little idea of the amount of work, there are around ~5100 Plasma5-related commits only on the plasma-frameworks repository, if we count all the workspace parts, it would be a way bigger figure.
It has been a long road, with some (quite) rough moments in the middle for sure, but looking back I’m pretty proud of what we achieved, of what i did, and what every single member of the team did to get here.
But this, this is

Just the beginning

This is the first release of a new chapter of Plasma, in which a new release method will be used to celebrate the diverity of the KDE community.
We used to have a 6 months “big release” of all things KDE, called in the beginning just “KDE”, then “KDE SC”, but this release is not that anymore, because KDE grown a lot in the past years, is not just that anymore, and “a single release of everything” scales only so much.

So, let’s take a step back and see what is KDE: it is a community that can offer you a range of very different things:

Want a primary user interface for your Desktop, Laptop, Tablet, Media Center? There is Plasma, tailored explicitly for the particular device is running on. Desktop and laptops have an interface optimized for mouse,keyboard and trackpad input, Plasma Active and Plasma Mediacenter are instead tailored on the constraints those different kind of device pose instead.
Do you need a particular application for a particular task? The KDE community offers a wide range of applications, from media players, communication tools, games, to a kickass office suite, to one of the best painting applications on the market (not best on Linux, not best among Open Source ones, the best, period) and countless others.
They are free software, they are multi platform and supported by a vibrant community of developers.
Are you a Qt developer that is working on a new application, and need more functionality? KDE Frameworks offers a wide variety of libraries and frameworks to chose from that can dramatically decrease the amount of work needed to do a big, polished application.
And in the latter case, if you want, of course your project is more then welcome to join in the KDE family, as other formerly external projects already did, like KDEnlive or GCompris

This release of The Plasma Desktop Workspace can be used for day to day use already, even tough it’s based on very new technology, so some youth problems are expected as well. Also, while the integration between KDE4 and Plasma5 applications is good, you may want to wait more applications ported to Frameworks 5 before jumply completely full on a pure Plasma 5 environment.

The cycle

So, when a new version will arrive? how do you check if new applications come?
The development cycle will be much faster now: you can expect a new release of the KDE frameworks (so the libraries, *not* the applications) every month, while Plasma5 will be each 3 months instead for now.
Anyways, new goodies should hit your distro of choice way faster than it used to be in the past.

Next time, I’ll write about what to expect in this release and the next ones about the user experience, the developer experience, and random musings on the future.