Why the Display Server DOES matter

This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message:

The result of this is the display server doesn’t matter much to applications because we have pretty good toolkits that already hide all this information from us.

Now I don’t know how to put it, the best description is that I’m shocked that Canonical is still not seeing the problems they created by having multiple display servers. I do not know how much experience Robert has with making applications work with multiple display servers, but I at least have this experience as shown in my blog post on making KF5 not crash on Wayland. Granted in this blog post I write that “basically if your application compiles on frameworks it will run on Wayland out of the box”. But that is a strong simplification of the issues which can be present.

With this blog post I will prove Robert’s claim that the display server doesn’t matter due to the toolkit wrong by contradiction. I could just stop here, because I already wrote that KF5 applications were crashing on Wayland prior to me starting to fix these issues. If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed.

Also the assumption that the toolkit behaves the same is just wrong. One of the issues I fixed was Qt returning a nullptr from QClipboard::mimeData on platform Wayland while it returned a valid pointer on all other platforms. It’s obviously an application bug but the documentation doesn’t say that there could be nullptr returned or not. There can be hundreds or thousands of such small behavior differences. An application developer is not able to ensure that the application is working correctly on a distro-specific display server. If the application developer recieves a crash report for such an issue, the developer cannot reproduce the issue – not even on running the same distro with another DE – cannot write a failing unit test, cannot integrate it into the CI system. The most sane thing he could do is declaring that proprietary display server as unsupported. And this should show the problem: each developer will see issues caused by Mir – it doesn’t matter whether it’s in the toolkit, application libraries or in the application itself. Thus an application developer will have to care about the display server. The applications will have to decide whether they want to support Ubuntu.

Another example is different behavior. Look at this screenshot:

Aus Weston

This is the KColorDialog running on Wayland and when I click the pick color button nothing happens and the debug output just says: “This plugin does not support grabbing the keyboard”. It uses QWidget::grabKeyboard – functionality provided by the toolkit. Again the documentation does not tell that it’s not supported on all platforms, it also doesn’t offer API hooks to figure out whether grab is supported. What will be a possible fix for this?

#if Q_OS_LINUX
if (!QX11Info::isPlatformX11()) {
    colorPickButton->hide();
}
#endif

We just hide the button if we are building for Linux but are not on X11. Why is that wrong? Well what if other platforms still support it. So a better way?

#if Q_OS_LINUX
if (QGuiApplication::platformName().toLower().contains(QStringLiteral("wayland"))) {
    colorPickButton->hide();
}
#endif

It’s better, it only hides it for Wayland. But what if the same feature is also not supported on Mir? How should a developer find out to fix that problem properly? How does a developer figure out what the platformName for Mir is? The documentation doesn’t know anything about Mir, the Qt sources (yes I have them on my system) don’t know anything about it. How long will it take till a user reports that the button is broken? Will the user tell that it’s Mir and not a normal system? After all our bug reporting tool reports “Ubuntu” for both Ubuntu and Kubuntu. And on Kubuntu, which the dev might be running, it’s working just fine.

Another example from a patch I prepared to fix an issue:

 #if HAVE_X11
     d->display = qgetenv("DISPLAY");
+    if (d->display.isEmpty()) {
+        // maybe we are on Wayland?
+        d->display = qgetenv("WAYLAND_DISPLAY");
+        if (!d->display.isEmpty()) {
+            // don't go into the xauth code path
+            return;
+        }
+    }
 #else

Now will that code work with Mir given the way it is written? Obviously not. Could I have fixed it? Obviously not, because I have no idea whether Mir has a system like these env variables. What will happen if someone tries to fix it for Mir? I expect the maintainers to tell that this doesn’t scale and needs to be reworked. For two it’s a solution to just test one after the other, but with three systems it doesn’t scale any more. It becomes too complex. So yes the maintainer of this application library has to care about the fact that there are multiple Display Servers.

In summary: Canonical created a huge problem by introducing another Display Server and it’s affecting all of us and they are still in denial state. It’s not a simple the toolkit will solve it. It can cause issues everywhere and that affects the development and maintenance costs of all applications. My recommendation to application developers is to never accept patches for this mess Canonical created. If they want that fixed, they should do it in their downstream patches. Distro specific problems need to be fixed in the distros. I certainly will not accept patches for the frameworks and applications I maintain. This is not for political reasons as it’s so often claimed, but for technical, because I cannot test the patches (Mir not available on Debian) and our CI system cannot build it.

Desktop Effects Control Module in KWin5

One of the new features in KWin 5 is a completely rewritten configuration module for our Desktop Effects. In KWin 4 our module was based on KPluginSelector, which is a great widget for a small list of plugins, but it was never a really good solution for the needs of KWin.

Also we noticed that a QWidget based user interface is not flexible enough for what we would like to provide (e.g. preview videos). So when QtQuick came around we had the first experiments with reimplementing the selector with QtQuick, but with the lack of what today is QtQuick Controls it never left the prototype state. But it encouraged us to use one GSoC project on redesigning the control module from scratch and Antonis did a great job there to lay the foundation for what we have now in the upcoming alpha release.

The most noticeable change is that the new control module just focuses on the Desktop Effects. What we learned from our users is that they are only interested in configuring the effects and that the other options exposed in that control module bare the risk of users changing and breaking their system. Thus we decided to give the users what they need and move all other options into another control module.

In order to give the users the possibility to focus on the effects we also did some cleanup in the list and all effects which are not supported by the currently used compositing backend are hidden by default (e.g. OpenGL effects when using XRender). Also all internal or helper effects are hidden by default. These are effects which replace functionality from KWin Core or provide interaction with other elements of the desktop shell. Normally there is no reason for users to change that except if they want to break their system. That’s of course a valid use case and so there is a configuration button to modify the filtering of the list to show also those effects.

Last but not least our effects got extended by information on whether they are mutual exclusive to other effects. For example one would only want to activate the minimize or the magic lamp effect. Both at the same time result in broken animations. For effects in a mutual exclusive group the UI uses radio buttons and manages that only one of the effects can be activated. That’s the change I’m most happy about.

Check out the video to see the new configuration module in action and also see some of the new features I haven’t talked about. Please don’t tell me in the comments about padding issues and rendering problems. We can see those, too, and are quite aware of them. If you want to help iron out issues with Oxygen and QtQuick Controls check have a look to our wiki page.

House Cleaning in KWin 5

We are currently approaching the release of the first alpha version of KWin 5. This is of course a significant milestone and we have put lots of work into the transition to ensure that it’s already working quite fine. With such a big migration it is also important to not only work on new cool stuff, but also to do lots of house cleaning.

For example last week the build option for disabling scripting support got removed as we consider scripting as an important and integrated part of KWin. Thus during the house cleaning the build option got removed.

And of course there are areas where we wanted to remove some legacy code for quite some time but never really dared to do. Two years ago I already discussed the costs of supporting the legacy OpenGL 1 compositing backend. Now it was time to re-evaluate the situation.

KWin 5 is a strong user of QtQuick 2. In fact almost all user interface code is written with this new framework – be it the close button in Present Windows, the window switcher or (since today) the outline shown when using quick tiling/maximization. QtQuick 2 uses an OpenGL (ES) 2 powered scene graph thus KWin already has a runtime dependency on OpenGL 2. And in opposite to our Compositor this is a required dependency. While it has always been possible to disable the Compositor (and that won’t change for X11), it is not (yet) possible to disable the OpenGL usage of QtQuick.

Thus we have to ask whether it’s still worth keeping a code path for legacy hardware, if we require newer hardware. Combined with all the problems mentioned in the above linked blog post from two years ago it becomes really questionable to keep the code.

After some preparation to ensure that we have a clean cut I pushed today the changes to remove the legacy OpenGL 1 compositor in order to have this change in Alpha 1. We encourage all users who used to run the OpenGL 1 compositor to try with the OpenGL 2 compositor and also with the still supported XRender based compositor. If you run into any severe issues please report a bug (or check whether one has already been reported) and provide the support information. This will help us to iron out any issues, like ensuring that no effects get loaded which are not suited for your hardware. After all the base OpenGL 2 compositor should not be an issue for most hardware. But some effects are more demanding than the compositor itself and those can be disabled automatically. Also we try to keep the impact low. If our logic recommended OpenGL 1 compositing for a specific set of hardware, it doesn’t enforce OpenGL 2 now, but uses the better suited XRender compositor.

“KDE5” and Wayland

Recently I have seen many comments by users in the style of “I’m looking forward to the first release of KDE5 because of Wayland”. With every time there is such a comment the chances are that it spreads that the first release of “KDE5” will support Wayland and will result in disappointment when the first release of something ends up on the users’ systems. Thus I decided to write a blog post with clarifications.

As my readers probably know there won’t be a combined release as the software compilation used to be. There are independent ongoing projects around the libraries (frameworks or KF5) the workspaces (Plasma Next) and the applications. These projects have independent release cycles and are not one product. I know, I know, many people will disagree and say that it’s still one. But if we go for this strong simplification both “will support Wayland” and “will not support Wayland” are true.

And thus we enter the area where it is important to make the distinction between the various products and use the correct name. Otherwise people don’t know what you are talking about and it results in confusion.

So let’s look into the different areas. As I have already explained our libraries are getting prepared for Wayland and the first release of KF5 will have Wayland support not on par with X11 support but certainly on par with Microsoft Windows or OS X support.

This means for applications using our frameworks that they will support Wayland as long as they don’t speak X11 directly.

For the workspaces it’s more complex. Our aim for the first release of Plasma Next has never been to fully support Wayland or do the migration to Wayland. We obviously don’t want to create too many construction sides and decided to concentrate on getting everything ported to Qt 5 first before going to Wayland. As we are entering the alpha release state shortly we can be quite certain that the Plasma desktop shell will not support Wayland. Other parts of Plasma Next have a little bit more integration, some systemsettings modules get hidden when running on Wayland, some modules got fixed to not crash, KInfoCenter got some improvements to support the OpenGL module on Wayland and got a new Wayland module. KWin is still in the experimental support stage not yet being a Wayland compositor. Here we might still have some improvements till the final release as Wayland specific code is excluded from the feature freeze. But overall we can quite certainly say that the first release of Plasma Next will not support Wayland.

System Tray in Plasma Next

In the past the system tray was implemented using the xembed specification. An application which wants to use the system tray creates a small window which gets embedded into the system tray. This means that the control over this area belongs to the application and not to the desktop shell hosting the system tray.

The result is that each item in the system tray may behave differently. Some set a different cursor, thus the cursor is flickering if you move from one icon to another. Some open/close the application when clicking the icon, some might provide a context menu on right mouse click or interact with further input events. But what is present in all cases is that there is no consistent behavior. From a user experience point of view this is very bad as the users learn that the system is inconsistent and works in an unexpected way.

Some years ago the Plasma hackers started to address these issues by implementing a new specification called Status Notifier. This specification got also adopted in Unity/Ubuntu as the Application Indicator. The new specification addresses the issues outlined above as the control is moved to the hosting desktop shell. This allowed us in Plasma to provide a consistent look and feel by using the monochrome icons and controlling which items to show when.

But still we supported the xembed system tray specification for legacy applications which were not adopted to the new specification. This means that all the issues are still present. It’s still possible that an item behaves completely different because it’s using the legacy protocol.

When we drafted the plans for the new implementation of the system tray in Plasma Next we of course also discussed the future of the xembed based implementation. It was a challenging topic as we want to go to Wayland and obviously an xembed based system tray icon won’t work on a Wayland powered system tray (yes in theory it could work through XWayland). Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task.

Also some of the design aspects just don’t work with the legacy system tray. We want to support reasonable dpi and xembed items are hard coded to 22×22 pixels, that’s probably a lot of fun on a high dpi screen. We also want to categorie the system tray items, so that they are logically grouped. For that the status notifiers allow to tell us that it’s an application item and whether it’s currently passive, active or demands attention. This gives the host the required power to properly place the item. But with the legacy system tray we are just lacking this information and don’t really know what to do with an item.

QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next
QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next

When we discussed all these issues it became apparent that we do not want to invest the time in implementing the legacy system for Plasma Next. Nevertheless we do not want to break the functionality of existing applications. So we investigated ways of how we can ease the transition. KDE applications use the status notifier already and most GTK+ applications also use the appindicator library for unity integration, so they just work the way we want it. But for example the QSystemTrayIcon still uses the legacy system on X11. As it’s Qt there is also the QPA-API which allows us to provide Plasma-specific implementations through our platform theme. That’s the approach we decided to go: force any QSystemTrayIcon to use the status notifier API through our platform theme. Unfortunately the QPA-API was not sufficient for our needs and thus we had to extend it, which will be available in Qt 5.3. If Qt base is compiled with X11 support the QPA system is not used at all and the change to fix this slightly missed the 5.3 merge window. The last missing bit to get this work is in our frameworkintegration repository to implement the required API. This is currently under review which means that it will be available once we release our first release of Plasma Next. Though it will take until Qt 5.4 till the feature will be working properly. As a nice side-effect this also adds an implementation for QSystemTrayIcon on Wayland/Plasma.

Although we invested lots of time into making it work as smooth as possible there will be applications for which the system tray icon will not be working. Nevertheless, we decided to not implement support for it as we want to focus on the core and it was not justified to invest lots of time on an implementation only needed for a short period of time. Applications still using Qt 4 will hopefully soon get ported to Qt 5 and then the issue fixes itself. Overall from an end-user perspective this means that nothing really changes. The system tray is still going to work, in fact it will be better as all items can be scaled, themed, behavior adapted to input methods, logically grouped and much more. Nevertheless it’s possible that there are applications which still use the legacy protocol and that will break. In case it’s an open source application it will be easy to fix and we as the Plasma team are happy to help as much as we can. And in any case Plasma is a very flexible framework allowing you to implement an alternative system tray which supports the xembed system tray. It doesn’t have to be the core team which keeps the compatibility with the legacy system.