KWindowSystem is a tier 1 framework which allows to interact with the windowing system. Historically it provided an implementation of NETWM on X11. It provides a NETRootInfo for accessing the global state (all that’s set on the root window) and NETWinInfo for all information about a specific window. The classes have a window manager and client perspective. This is the foundation which powers our window manager and various parts of the desktop shell such as the taskmanager.
On top of those X11-specific classes we have a convenient API KWindowInfo and KWindowSystem which provides a windowing system independent API for our applications. Thus we have different implementations depending of the platform it’s compiled on. On X11 the implementation depends on named NET* classes, on Windows and Mac what makes sense is implemented using the platform specific API.
In the good old days of Qt 4 this was a sufficient solution. If it’s build on unix-like systems we have X11 and we know it’s X11, on Windows it’s Windows and so on. With Qt 5 this no longer works. Just because we built with X11 support doesn’t mean the software will run on X11. Due to the introduction of the QPA it’s possible that another platform is used – most obvious Wayland. But there are more platforms for Linux like Android. With the solution from Qt 4 our applications would just crash as soon as they access KWindowSystem as that tries to interact with XLib/xcb unconditionally.
Over the last weeks I spent quite some time on making sure that KWindowSystem works as expected (that is doing nothing at the moment) when run on Wayland. Just adding a new implementation as in the Qt 4 days is no solution as we want our framework to support both X11 and Wayland at the same time. Otherwise our distributions would have a hard time packaging our software. The approach was to introduce an internal abstraction in KWindowInfo and KWindowSystem and have a platform implementation. This is now done for X11 together with a dummy implementation which is used as a fallback if we do not have an implementation for the currently used windowing system (e.g. Wayland). Unfortunately this has a side-effect: it broke the backend for Windows and MacOS. I don’t feel very happy about it as I don’t like to break the work of others, but I cannot fix it. Windows and MacOS are proprietary systems for which either a license or even specific hardware is required. I do hope that the specific teams will re-add the support till the release of frameworks 5. Please note: at the time of writing this blog post not all patches are merged yet.
A nice side-effect for this work was that I started to write unit tests for KWindowInfo on X11. This is far from trivial as it interacts with X11 and the running window manager. And the test kind of depends on the used window manager. Obviously given that it’s KDE it would make sense to write the test against KWin, but that’s not sufficient for our CI system as kwindowsystem is a dependency of KWin and thus kwindowsystem cannot depend on KWin (not even on runtime). Thus the tests are now performed against openbox on the CI system, but also succeed when running against KWin. They are quite a stress test for a window manager and found one very unlikely crash condition in KWin (of course already fixed).
The framework provides more functionality which is kind of X11 specific. For example there is the KSelectionOwner and KSelectionWatcher which implements a manager selection as described in ICCCM, section 2.8. Again a very important building block for our window manager. While it’s clearly X11 specific code which only gets built if X11 is available, there is no reason to crash if it’s not run on X11. So I went through all of our sources and tried to make sure that it correctly checks whether the runtime platform is xcb. Thus we don’t have to change all applications using it, but can rely on the library not to crash. Still if your application is using these X11 specific functionality I highly recommend to check for the platform as you might run into runtime errors. E.g. claiming a manager selection will fail, don’t rely on it.
As all of this is kind of a requirement to running frameworks based applications on Wayland, I have to do the obligatory screenshot of Kate on Weston:
 |
| Aus Weston |
Great work! Looking forward to KDE Frameworks 5 on Wayland!
I love this kind of work. I just really hope someone comes along to fix the Windows stuff, because I’m a heavy Kate user on both Kubuntu and Windows.
Great work, I instead hope Windows support will never be added so people will be likely to switch to GNU/Linux just to use our fabolous programs. I think only few programs need to run in multiple os to ease migration. I.e. pushing KDE and GNU/Linux in schools I’m often asked “oh, nice Free apps, but do they run on windowns also? yes? So why go for GNU/Linux, since in Windows we will have all the proprietary apps PLUS your free(dom) ones?”. Instead would be great having stunning apps that just run on GNU, like Apple does.
Unfortunately, this would only be ‘great’ from a marketing perspective. Of course, it’s always better if we can have more people using good free software, but forcing people to change their dgital lifestyle just to have a few good apps is the kind of trouble Microsoft and Apple are eager to inflict on people. We shouldn’t join them, as I doubt we would get many new users that way, anyway.
We need to improve our market image to the level Apple has in order to hoodwink people like that, and I’d say it’s not morally worth it. That said, I’m not that upset if improving our software requires leaving a little-used platform behind for a release or two (little-used meaning KDE software isn’t very common on Windows or OS X at the moment). I’m just afraid that this mindset is spreading even within our own community. Now that desktops are focusing on more cohesive experiences, supporting apps across environments is becoming less of a priority. I don’t think that’s as necessary as people want to believe.
Of course, with projects run largely by volunteers, it’s hard to justify spreading resources that thin, so I’m not bothered by it so long as it’s an unintentional side-effect of doing good work, as in this blog post.
This seriously could not come out quick enough. It seems like I have been waiting for wayland forever but with news like this it’s good to know it will not disappoint.
Neat! I created a tap for homebrew at https://github.com/haraldF/homebrew-kf5 hope to get some more stuff working soon 🙂
Looking at the Kate screenshot now, it should probably say “using KDE Frameworks 4.96” rather than “KDE Dev Platform”…as platform actually refers to kdelibs, right?
I think platform is still right. But that’s something to raise at the frameworks mailing list.
If I understand correctly, KWin uses Weston at the moment. Will KWin be a full Wayland compositor eventually?
No, KWin doesn’t “use” Weston. KWin is currently not yet a Wayland compositor, but can render to a Wayland surface instead of an X Overlay Window.