KWin meets QML

Two years ago I started to re-implement the Window Switching capabilities of the KDE Plasma workspaces (also known as Alt+Tab or TabBox). The old implementation was based on a QWidget with custom painting which of course had some drawbacks. The new TabBox evolved into a framework around Qt’s Model-View concept to design your own window switcher.

Before I started to work on that area I did evaluate the existing Window Switching capabilities of the various desktop shells (both free software and proprietary solutions) and I noticed that all of them have drawbacks. None is the solution where I would say: that’s the perfect switcher.

The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.

So I realized that we need something flexible enough to give users the possibility to use different layouts or to even define their own layout. This ended in a framework for window switching. The layout is described with an XML file and rendered through custom painting code in a Qt delegate.

When I implemented this framework I wanted to add a GUI to easily configure own layout. Unfortunately I never got around to implement this UI and I think there has never been any other layout except the default shipped once. It is a rather unknown feature and I’m quite unhappy that this great functionality never got implemented.

In the mean time the trolls did a great job to make UI development easier: QML. This makes it possible to do what I wanted to have for window switching: easy to design and exchangeable layouts. So this weekend I implemented the default (informative) layout in QML and plan to completely replace the existing View and Delegate code in 4.8. And this gives us the possibility to let users write their own layouts and to share and exchange them.

But this is only the beginning of usage of QML in KWin. I have many more ideas by making window thumbnails available to QML UIs in a limited way. This will allow us to even integrate the BoxSwitch effect into the normal window switching framework and replace the Window Strip in Plasma Active.

So great UI times ahead in KWin.

24 thoughts on “KWin meets QML”

  1. Thank you for your great work! About the perfect windows switcher, one feature that IMHO is really nice is the ability to close a program from the Alt + Tab menu on MacOS (using CMD + Q). I know you can do that in KDE but you have to use the mouse, which can be annoying. I would love to see that functionality.
    Again thank you for all the great work!

    1. I did not know that MacOS supports that. It would be easy to add, but I find “Q” dangerous being the key next to “Tab”

      1. Obviously when unsaved documents are open, it asks first.
        In kwin I’d guess it lists windows, not apps. So implenting that functionality would involve W not Q.

        Ps: you rock!

    1. It mixes a little bit Activities and Desktops, but after I did the Effects integration for QML that should be possible

      1. That would be lovely. It’s like the OS X mission control, but i used it and it’s really cool. But not only this, it is helpful and gives the user a nice desktop experience in everyday work. If you could some day implement that, i would love you more :D

  2. “The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.”

    This is great summary about why KDE is for users and Gnome is for developers that develop it.
    Keep up the good work!

    1. If I were to play the devil’s advocate, I’d say that on seeing a difficult problem (and it IS a difficult problem!), Martin has chosen not to decide, to shy away and instead foist that decision on the end user who just wants to get their work done.

      I don’t necessarily agree with what I just said there and we can both see I purposefully used inflammatory language to make a point. However I hope you can appreciate that whilst dealing in absolutes is fun and enjoyable, it’s almost never accurate or useful. I could equally turn your sentence around and say that KDE expects its users to be developers! Both KDE and Gnome have made compromises here – regardless of which group we think has made the right ones!

      1. Martin has chosen not to decide, to shy away and instead foist that decision on the end user who just wants to get their work done.

        I have to disagree: by default we have a pretty decent switcher which works for most users. Those users who just want to get their work done are suited well with it and will never find the config options.

        Those users who need more possibilities on the other hand get it.

  3. The progress made on KWin always exceeds my expections… truly spectacular.

    I remember that there was some talk about QML based window decorations, any progress on that side and what kind of benefits would it have compared to current system?

      1. You would still need a wrapper like Aurorae, but yes it would be possible to design Aurorae themes using QML if someone implements it.

    1. Perhaps it would be possible for QML-based titlebar *buttons* as well. A feature I enjoyed about an FVWM desktop I used to use was the ability to place a close (X) button on each side of the window. KDE does not let me do this; there can be only one instance of each type of button, as far as I’m aware. A QML decorator could allow custom button images and behaviors.

  4. >I have many more ideas by making window thumbnails available to QML UIs in a limited way.

    Does that mean building something like gnome shell would be possible with plasma + kwin?

    1. It already is possible, just nobody did it yet. There is GNOME Shell for those who want to use GNOME Shell, we don’t need to duplicate that work.

  5. Firstly thanks for your amazing work! This is really the right direction to go.

    I have an issue that there’s always some noticeable latency between ‘alt-tab’ key press and the window switcher shown. I tried all window switchers, changed “Animation Speed” option in “Desktop Effects” panel to “Instant” and even disabled composite but the latency is still there. This is annoying for fast window switching.
    For comparison, I tried openbox and gnome shell, and the switchers show up quite instantly.

    1. The latency is intended to allow quick switching to the last open window without the overhead of showing the box.

Comments are closed.