SDDM v0.15.0

SDDM is a Qt based Display Manager used by multiple desktops, but most importantly (certainly for the PlanetKDE crowd), KDE.

After a year of seemingly little activity, I've released SDDM v0.15.0
It is mostly a bugfix release with important changes, but nothing to get particularly excited about.

For full release notes please see: https://github.com/sddm/sddm/wiki/0.15.0-Release-Announcement

Now this is out, I shall be merge a huge queue of pending larger changes - hopefully we shall see 0.16 in only a few months.

KWin Wayland Independent Monitor Scaling

We want:

  • Legacy apps at the same physical as modern apps that support high DPI
  • Apps and window decoration to work across multiple screens at different DPI
  • Consistent mouse speed and input across monitors of different DPI
  • What we want to see:
    What we want to see

    What we need to render
    What we need to render

    How it works:

    In order to have a normalised co-ordinate system between monitors and to support apps that can't scale themselves the system is defined as follows:

    * KWin pretends all monitors are ~96dpi and handles all communication and input co-ordinates as such. Final output is then scaled up if applicable

    * Clients which support high DPI, when relevant, will provide a buffer (the picture of their contents) which is twice the resolution of their window size.

    This covers all the different scenarios:

    If we have a 1x window on a 2x screen, the compositor will draw the window twice the size.

    If we have a 2x window on a 1x screen, the window contents will be drawn implicitly downsized.

    If we have a 2x window on a 2x screen, the window will be drawn twice the size, but because it's at twice the resolution, we end up painting the contents at the native resolution.

    Clients without scaling now work as intended, I can use ardour or xfig on my high DPI screen and can read and interact with it normally (albeit obviously at standard resolution)

    The mouse even moves at a consistent speed across monitors and even if you had two touch screens at different DPI showing the same content, both will work perfectly.

    The changes to kwin were therefore really small, and mostly was not about implementing features but more about removing an assumed coupling between a texture size and the rendered size.

    FAQ

    When?

    The code to do all of this is in Plasma 5.10 as a hidden feature whilst we get more testing with everything except a UI to configure it. This is ready to land for 5.11 An extra problem is that Qt < 5.9 has a bug if the screen scale changes dynamically.

    What's left?

    Using this technique means everything is at the right size, but some adjustments are needed to make sure everything appears at native DPI not normal DPI. This is something being fixed over time.

    What about fractional scaling?

    The wayland protocol specifies a scaling in integers. We can't really go against the protocol. However, there's absolutely nothing against kwin scaling to a different amount to the protocol. It's something we can expand on later.

    Dave’s QML Binding Loop Backtrace Printer

    Binding loops suck, and they can be hard to fix. I wrote a tool that prints a backtrace of the bindings being updated when a loop occurs. See link at bottom.

    About:

    QML bindings are a very fast and easy way to write a declarative UI. However it's quite easy to accidentally write an infinite loop.
    This can happen if we bind propertyA to affect propertyB and also bind propertyB to affect propertyA, they would constantly update each other.

    Consider the following example:

    1 import QtQuick 2.0
    2 
    3 Rectangle {
    4     width: childrenRect.width
    5     Text {
    6        text: parent.width > 10 ? "Hello World" : "Hi"
    7     }
    8 }

    The Rectangle width changes on startup, that changes the text's size, which in turn changes the Rectangle's width. If this was undetected the application would loop forever and eventually crash.
    QML prints a warning, and ceases processing, but it's an indication that something is wrong with the logic of your code, and it needs fixing.

    However, whilst the loop here is obvious to spot, it can be considerably more complicated when looping through tens of bindings over many many components.

    Creating a Tool

    The problem with this warning is that on its own is rather unhelpful - trying to find the loop then becomes a manual task of tracing all possible combinations through every bindings that could lead to a short circuit. GDB on its own doesn't help as the C++ backtrace tells us absolutely nothing we can use.

    I've created a small script that, using gdb, unwinds the backtrace detecting where the properties changed and then showing the QML code which is responsible.

    Simply download here into $PATH and run with

    "binding-loop-tracker.py myAppName"

    In the case of the loop above we will see output like:

    =====Binding loop detected - printing backtrace =====
    #0 - file:///home/david/temp/binding_loop.qml:4:12
    #1 - file:///home/david/temp/binding_loop.qml:6:15
    #2 - file:///home/david/temp/binding_loop.qml:4:12
    

    Which shows which line of QML was being updated when we hit the loop.

    It still requires some manual work to follow the trace through, but it's a useful aid and has already helped me in two real world cases that I couldn't resolve manually.

    Building stable branches with kdesrc-build

    When coming up to a release it's important to track the stable branch of a project so that we're actually running what we're going to release and can put our focus on fixing any remaining tiny bugs.

    If you build all of Plasma with kdesrc-build you can easily switching to building the stable release with the following command:

    kdesrc-build --Branch Plasma/5.7 kf5-workspace-modules

    To change back, simply emit the --Branch parameter.

    My Randa Plans

    The Randa meeting starts this week, and I'll be working with the KDE multi-platform group, being led by Aleix Pol, and will be spending my time working on both flatpak (formerly xdg-app) and Snappy.

    During this past week I have been brought into some technical discussions about deployment on both platforms; so I intend to spend my time working closely with other interested developers solving problems that affect either platform as there is a lot of overlap. Tackling these independently doesn't make sense.

    These two emerging technologies both have a lot of potential to revolutionise Linux packaging and distribution with either being a huge boost over the current state.
    Both are going to become relevant in the Linux world over the next few years, and the important thing is making sure our software works best for our users whatever the platform.

    So far over this week I've spent some time fixing KDE flatpak applications, in particular fixing multiple problems we've encountered with Dolphin; namely being able to load plugins and making kio slaves work.

    In the meantime I've been testing out packaging some Snappy apps, packaging and running a few applications.

    Over the week I'll write some more in depth blog posts, exploring the state of each, where we have problems deploying our apps, and hopefully some concrete solutions 🙂

    Be sure to sponsor the sprint to help pay for developers from around the world to come together to work on important projects and be sure to follow PlanetKDE for blog posts about software developments from the people here.

    PlasmaShell Sans GL

    Since Plasma 5, the main shell is powered by QtQuick, which till now brings a requirement on a working OpenGL setup. This causes problems for Plasma in situations where we can't run OpenGL; either extremely cheap hardware, xrdc or when a user upgrades and breaks their nvidia setup (a seemingly common occurence).

    Qt 5.6 brings a new module which opens some interesting possibilities; the QtQuick 2D renderer, which avoids that.
    This has existed for a while, but it has only recently been open sourced as GPL3.

    QtQuick Internals

    QtQuick is powered by a scenegraph.

    Each graphical item updates a tree containing nodes containing either transformations or content. That content being either a rectangle, a picture or a custom openGL shader from the application. The important part is that it stores a tree of items in an way optimised for rendering, but also acts somewhat as an layer between any QtQuick component and the underlying OpenGL renderer.

    Using the QtQuick 2D renderer

    The QtQuick 2D renderer still uses the same scenegraph, so all custom QQuickItem's which use the standard QtQuick SceneGraph nodes still work, but instead of calling OpenGL functions, calls are mapped to a raster backend instead.

    The Result

    My personal desktop, running Plasma using the QtQuick 2D renderer. The screenshot shows some of the parts working, but also highlights some of the bugs

    Performance is surprisingly fast, not faster than the OpenGL backend, but plasmashell still remains perfectly usable on my desktop.

    Most of the basic scene graph nodes have a 2d renderer implementation, however any node that does custom openGL, such as QtGraphicalEffects or certain parts of Plasma, will simply fail.

    What's broken

    There are plenty of known limitations with using the 2D renderer, some cosmetic, some more fundametnal.
    Qt provides their own list.

    In terms of Plasma, the list of broken items are:

    • We have our own GL check in the shell that needs adapting
    • Icons were broken. We implemented our own shader whilst animating between states rather than uploading a new pixmap per frame. I fixed this by simply turning that off.
    • Our load monitor plasmoids are pure GL. I've made a patch that makes it not crash. Making it actually work would mean having two implementations...which isn't a route I really want to go down.
    • Widget explorer is broken, again we have our own shader for some effects
    • We are missing a lot of minor graphical effects. Fewer shadows and alike, but that's a hit I think we will just have to accept

    Summary

    In general it seems that with a relatively small amount of work this might be a valid option for users without working openGL.

    It will always be a second class citizen, but it should be do-able to support without hindering progress for the vast majority of users.

    What's interesting is to see how easy it is to support a different scene graph backend, as it is a clear indication of what we will encounter when it comes to Vulcan in a few years time.

    Neon and Plasma Relationship

    As we saw neon, a new and fresh Linux distribution was launched last week. This project is incubated by the KDE Community, sharing KDE's hosting and community. Hopefully we'll see neon flourish into an awesome distribution over time.

    However, I have seen some potential confusion in an article reaching a conclusion that this might be in some way problematic for other distributions to deploy KDE software. To make sure we're all on the same page I wanted to give a clarifying statement from the Plasma mantainer.

    Plasma is and remains distro-agnostic. It's in our interest to help all of our distribution channels. As long as distributions continue to keep up with the dependencies we need and work well with us, we support everyone as best as we can.

    My new widget in Frameworks

    One of the new features coming to Frameworks 5.15 is my new widget KCollapsibleGroupBox.

    Acting like QGroupBox it allows you to hide some of the more advanced options out the way till the user expands the header revealing the rest. A common web pattern, but lacking in Qt or KF5.

    Good for making a long list of pages navigable or hiding features that only a small fraction of users will find useful.


    simple by default, powerful when needed

    Handy, but mundane. Why the blog post?

    There's no point in writing a new class in a library if no-one knows about it.

    Also I wanted to highlight two more interesting topics:

    Working with the VDG

    The main reason I wrote it was because every mockup given to me to by the VDG, especially from the usability expert Heiko Tietze, invariably featured this widget somewhere.

    Our resources need to match what's being requested from our design team as described by Thomas in his recent blog post.

    Bringing our QWidget library forwards

    Another important aspect that's worth broadcasting is how we're still moving our QWidget libraries forwards. Whilst there's talk about them being outdated or replaced, that's really not the case; and still definitely the best candidate for building any serious desktop application.

    This isn't the only new change; there's still a lot of areas that can and should be improved to modernise our platforms for the current set of applications.

    Legacy system tray icons back in Plasma 5

    Didn't we drop support?

    Legacy system tray icons are problematic; they don't scale, they don't fit in with the theme, they can't multiplex (be in two trays) and they're just generally very dated.

    We came up with a new scheme Status Notifier Items (SNIs) back in 2009, which was also adopted by our friends at Ubuntu in Unity, which provides logical information over DBus about what to show, rather than just an arbitrary window.

    Our existing xembed code needed an entire rewrite, given wayland would also break xembed it seemed a more useful investment of time to make sure most the toolkits supported the SNI specification than work on the rewrite.

    In retrospect, I think we underestimated the fallout this would cause. There are propreitory apps, more random toolkits that weren't covered, and some distros didn't apply all the patches needed

    There's nothing wrong with changing our minds in response to user feedback.

    Restored Support

    Having decided that we can't drop support just yet, it seems unlikely we can drop it in a few months when we switch to Wayland. So we need to consider how to make that work there. Embedding an X window inside a wayland window isn't going to work.

    My solution was a hidden process, xembedsniproxy, renders the embedded windows offscreen then uses the existing SNI specification to inform Plasma. Plasma gets support, including multiplexing without really knowing about X.

    It should be as seemless as anything else.

    Current State

    It's at a state where it's usable, but there are undoubtedly still some bugs. Every toolkit has their own quirks regarding system trays.

    Please leave a comment if you find anything.

    The code is currently in a test repository here

    It is available already in yaourt for Arch users:
    aur/xembed-sni-proxy-git

    I hope to have it merged into Plasma for 5.5, depending on feedback.

    Just another manic monday

    I love project stats, and I completely obsess over bug reports.
    Whilst collecting data for another post, a mystery libreoffice autocomplete popup me to plot something I hadn't thought of plotting.

    What days of the week are bugs opened and closed?


    Resolved can mean one of a few things; fixing the bug with a change in the code, marking it as a duplicate of another bug or in some cases closing it as not a direction we want to go with Plasma.

    Observations

    People report more on weekdays than weekends

    The difference surprised me. I think it gives a strong indication that Plasma 5 is being used more for work than as a hobby, with people more likely to encounter an area needing to improvement during the normal office week.

    Obviously we don't know for sure and we can't pull useful timestamp information without knowing timezone of the user, but indications seem to be there.

    Bugs are resolved on a weeked at 50% of the rate of the weekday

    This isn't too surprising given that some Plasma maintainers like myself work for Blue Systems or Red Hat and we tend to work office hours.

    What's encouraging is that, whilst slower, this shows that a significant amount of work does happen outside office hours; both employees taking the extra time to care for Plasma and our community contributors stepping up to work here. There's some shift between the people doing weekday and weekend bug closing.

    We get more bugs open than we close

    Naturally our graph will show that we have some open bugs, but if we assume this rate continues our number of open bugs will continue to rise.

    It's not as bad as this graph makes it look as there also a lot of bugs in a zombie "needs info" state, where we're waiting to hear back from a user either with more information or to confirm their issue is fixed.

    We definitely need more help here, I want Plasma to be bug free.

    It's all about Tuesdays

    Tuesday is apparently the day for the most reports getting handled. It's also the day Plasma 5.4 gets released.

    I always knew Tuesday was an underrated day of the week.