Hitting walls – a story of Present Windows 2

One of my favorite User Experience elements in KWin is the Present Windows/Desktop Grid combination. For me those are the most important elements to switch between windows and virtual desktops. Although Present Windows and Desktop Grid are two different “effects”, I consider them us one because of their very similar functionality. The primary use case for both is to change the active window, the main difference is that Desktop Grid sorts the windows by virtual desktops.

The effects are so similar that they even share the code to lay out the windows. Nevertheless there are quite some differences in the functionality. The following features are only available in Present Windows:

  • Filtering of windows
  • Icon and caption on each window
  • Closing windows through a button shown on hover
  • Enlarging windows on hover
  • Mouse Actions
  • External activation (used by Netbook Shell)

On the other hand there are features in Desktop Grid not available in Present Windows:

  • Drag windows from one screen to another
  • Add/remove virtual desktops

The difference in functionality cannot be explained – there is just no reason for it. This is clearly a problem for our users – the effects look identical, but they behave differently. From all I learned about usability this is pretty bad because it teaches users to not trust systems.

The obvious answer would be to merge those two effects. But here we have a problem. Present Windows has been implemented to be Present Windows – no matter how we tweak it, it will be Present Windows. And Desktop Grid has been implemented as a Desktop Grid – no matter how we tweak it, it will be Desktop Grid.

I know that people will tell me that nothing is impossible. Of course one could hack around and make the effects be the same. But we have been there and tried to bring non-Present Windows functionality into Present Windows. I once implemented an Alt+Tab mode in Present Windows – a huge mistake. All it did was adding lots and lots of special case handling to make it work. And it castrated the effect. It only supported one screen (needed of course special hacks), it didn’t support filtering (keyboard grab hold by Alt+Tab framework) and so on and on. It never made any sense and I am very glad that I realized this error and removed the Alt+Tab mode again.

But also with Desktop Grid we made the experience by adding the layout mode of Present Windows. It wasn’t good for the code base. Nowadays, after I implemented that addition, I compare the code base of Desktop Grid effect to a Jenga tower which is already shaking and I fear that if I touch it to change something it will completely collapse.

A merge would only be possible by removing features and that is always difficult. People were really upset when I removed the Alt+Tab mode of Present Windows. Arguments do not work, giving replacements does not help and trying to improve the workflow is of course not welcome.

What remains would be a complete rewrite from scratch. But that’s a task so large that I consider it as a possibility for a Google Summer of Code project. Together the two effects have more than 4000 lines of code. It’s nothing we could do in parallel to our normal work and rewriting as a KWin Effect does not really make sense. Yes one can use Effects for that but it’s rather limited.

One of the most clear disadvantages is that Effects require Compositing. While having always composited systems becomes more and more the reality, there is still no reason why there should be the break in the user workflow when turning off Compositing and I have had many discussions with users who did not understand that.

But the real problem is that we do not have a toolkit inside the Effects. We are down to key press/release events and mouse motion/press/release events. That’s rather limited. For the close button inside Present Windows we do quite some hacks to get the mouse events injected into the QWidget. It’s a hack and nothing that scales. Key events are not composed correctly – for example on my English keyboard I’m not able to write letters like “ä, ß” in Present Windows. But the real problem is the handling of things like the drag and drop of windows in Desktop Grid. The code is extremely nested (seven indentation levels) and has to cover many, many corner cases. It just shows how difficult it is to get that handled correctly with different modes.

But since recently we have a technology which solves many of these problems: QML. With QML we get a toolkit which we can use to properly interact with the windows and which is supported in both composited and non-composited setups. In combination with our KWin scripting framework we have capabilities which are quite similar to what our effects can do. As a nice side-effect QML forces us to separate logic from visualization which means that the logic of Present Windows/Desktop Grid could be reused and combined with new ideas of how to represent the data.

This week the logic part entered KWin’s source repository in form of a QAbstractItemModel which is exported to QML. The model is quite flexible and allows to sort the windows in multiple levels – currently it supports screens, virtual desktops and activities. In addition one can specify whether a window should be excluded. That’s for example important to have the different modes of Present Windows – there is one mode for only current desktop and one mode for only windows of the currently active application.

Having a model makes it rather easy to support filtering – we just need to connect it to a QSortFilterProxyModel and such a model is already provided and exported to KWin’s QML binding.

Implementing the logic for Desktop Grid inside QML becomes now as simple as:

ClientFilterModel {
    id: filterModel
    clientModel: ClientModelByScreenAndDesktop {
        exclusions: ClientModel.NotAcceptingFocusExclusion | ...
    }
    filter: filterItem.text
}

The idea is now to use this as a base for what I call “Present Windows 2″. It’s nothing I target for 4.11, because of the complexity of Present Windows and Desktop Grid. I hope that many things become easier once we are on Qt 5 and QtQuick 2. So it’s something I want to have for Plasma Workspaces 2. I’m still wondering whether to optionally include the current proof of concept QML script which renders a screen like this:

Aus KWin

One can already see the improvements like an always visible filter area. That’s one of the real disadvantages of the existing Present Windows effect: one doesn’t get any hint that it is possible to filter the shown windows. Also a clear improvement in this variant is the always visible close button for each of the windows.

The new models included in KWin might also get new tasks I haven’t thought about when I started to work on it. Our Plasma developers noticed that this would be a rather good base for the tasks applet. Whether that’s possible or not we do not yet know, but it would have clear advantages to have a shared code base for all the different ways of getting an overview of open windows.

(Sorry for having once again written such a long blog post)

18 thoughts on “Hitting walls – a story of Present Windows 2

  1. Hey, don’t be sorry for the long blog, it’s a interesting read.

    I’m one of the ppl who was unhappy with the removal of the ability to switch between windows using Present Windows as it was just very nice. I now use the “Windows Wall” script to switch, which doesn’t suffer from the issues the Present Windows clone did. But otherwise, it does the job, and the plugin system for alt-tab is real nice.

    QML based solutions seem to fit better with the style of the desktop, the current kwin effects seem more openGL-y. Fancier but less ‘connected’.

    1. QML based solutions seem to fit better with the style of the desktop, the current kwin effects seem more openGL-y. Fancier but less ‘connected’.

      Totally agree – we are clearly lacking here the proper integration. QML will hopefully help here, though I have no idea yet how a Present Windows 2 will look like in a Plasma Workspaces 2 world. Maybe similar to dashboard…

  2. Seems that you have removed the stupid enlarging effect, and replaced it with beautiful highlight around. For me that’s the best news. ; )

    I’ve recorded a video of compiz’s scale plugin. Maybe you can get some inspiration from it: https://vimeo.com/63907699

    1. Hey, I like the stupid enlarging effect. Together with the non-focused windows being dimmer, it makes it very clear which window is selected.
      The highlight in Martin’s screenshot would be too hard to see on a short glance for my taste, but I don’t want to start a flame war now ;-)

  3. In the present Windows Effekt Settings, you can add something like:

    o Activate Desktop Grid Features:
    (Drag windows from one screen to another)
    (Add/remove virtual desktops)

    So the Users only see one available Option in the List, choose between them (or activate both) and maintain the personal overview ^.^ Yes ?

    1. That doesn’t really help anything, because the features would need to be added to Present Windows and that’s the difficult part (and the reason why the post is titled “Hitting Walls” – we hit a wall there).

      1. So it is not possible just to let it look like it is a feature from Present Windows – and in Facts, the Checkbox, activates and disables Desktop Grip ? Why is the Settings Dialog limiting like that ?

  4. I too use present windows and desktop grid all the time. I even have present windows (all desktops) mapped (xbindkeys + dbus) to an extra button on my mouse, which makes using it really streamlined.

  5. @martin
    not related to this one but do you know the ‘workspace-strap’ effect? it’s from a year ago.. or 2? I don’t know. But will it be hart to port it to current kwin/make it available for one of the next releases? It was a hyperusefull effect. for a 2-or-more-workspace-hater like me. but it dont work with newer and current versions of the KDE workspace.

    is there a chance for?

    http://kde-apps.org/content/show.php/?content=143857 this one

    1. I know that this effect existed, but I never tried it. Our effects API/ABI is not stable, we adjust to each release. If an effect is not integrated in kwin directly it’s very likely that it breaks. That’s why we do not recommend to do so and nowadays have the JavaScript and QML bindings. How much work it is I do not know, just that an adjustment to 4.10 would not help to get it work with 4.11.

  6. It’s great to have those two effects unified. On the other hand, can we have the task bar observable (as in the conceptual figure in your post)? Then new windows can be launched without quitting the present windows when no instance of window exists.

  7. Very interesting work. I do not know how final the design is, but just as a recommendation:
    I think putting the close bottom in the upper right coner instead of the lower right corner would make the desktop more consistent in the default configuration.
    Additionally the space between the button and the window seems to be too large, thus the connection is kind of lost. In fact, the close button of the left window in your screenshot is closer to the right window than to the left window …

    1. one of the ideas I had was using the real window decoration for thumbnails. So only the window content would be scaled down.

    2. Hi

      > “I think putting the close bottom in the upper right coner instead of the lower right corner would make the desktop more consistent in the default configuration.”

      That was one of the things that made me fork the QML “present windows clone” and play around with it. Well also a bug with the mouse handling. The result is called “windows wall” for lack of a better name.
      I realised fast that QML gives lots of power to tinker with the UI but also that the bindings are not exposing enough yet to make such complex things as the original “present windows” or even more ambitious UIs.
      Nevertheless, good news that there is something happening to improve that situation as I think there exist many different workflows among KDE users. With the ease of QML more window switchers or as Martin put it the combination of switchers and application managers should come up. For example take this nice project http://workflow.opentoolsandspace.org/ that I am a happy user of because it made the management of windows with activities finally not a pain in the ass anymore. It contains all the features that Martin mentioned above about filtering and moving windows and adding desktops etc. and it is mostly in QML. The developper is at the moment thinking about the same question if to combine his plasmoid (also available as kwin script/effect), which is more akin the Desktop Grid, with the Present Windows and have both in one.
      Btw, while developping the plasmoid the developper stumbled across a couple of bugs that are present in KDE concerning virtual desktops, activities and plasma. So having people innovate in this area by implementing new ideas helps to improve the desktop experience for all :) .

Comments are closed.