Posted on by Martin Flöser

An update on KWin on 5

I realized I haven’t written a blog post to highlight the latest changes in KWin for quite some time. The reason for this is that we currently are mostly focused on getting KWin to work on Qt 5/KDE Frameworks 5. As I have mentioned already in the past KWin is a little bit special in the transition to Qt 5 as we used the low level native, non-portable functions provided by Qt (last week I found one usage of a native function which is not even documented). For us it mostly means that we transit from XLib to XCB and remove code which uses methods which got removed or replaced.

Although that means that we hardly have any new features there are quite some improvements all over KWin. Having to touch the code anyway allows us to also rethink how we tackle a problem.

For example we use Plasma functionality at a few places. The code got added before QtQuick existed so it uses QGraphicsView. With libplasma2 the QGraphicsView support is going to be removed which means we need to adjust our code. Over the last years some areas in KWin already made the transition from Plasma styled QGraphicsView to QtQuick, such as our Window Switcher or the Desktop Change OSD. But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid. Here we have now a nice improvement ready for 4.11: these elements got rewritten in QML and they look way better now.

Aus KWin

For comparison just do Ctrl+F8 or Click here.

This was AFAIK the last bits of UI in KWin which hasn’t done the transition to QML yet. By using QML for all of our UIs the code becomes much easier to maintain, easier for users to improve it, easier to style it. The last point is really important for KWin adjustments for non-Plasma environments like Razor-Qt. Though they use a fair bit of Plasma styling already and with KF5 libplasma2 will be so small that it hardly matters 😉

The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow. This change became possible because the screen edge related code was one of our strongest user of XLib and a refactoring was needed anyway to support the world after X. The new design follows an approach which will make it easy to add support for a new windowing system – even if I do not know how exactly that will look like in a Wayland world (currently Qt5 is the highest priority). Also we plan to make KWin take care of the screen edges needed for the Plasma Panel. This removes quite some duplicated functionality from Plasma and solves the general “problem” that Plasma cannot listen to just all mouse events in a Wayland world.

One of the areas which has seen most adjustment so far is our XRender based compositor. It was a heavy user of the QPixmap/X pixmap relationship and needed to change. I still consider XRender as an important part of our compositing offering and therefore decided to do the porting. Interestingly the porting did also bring improvements to our OpenGL compositors. Again the reason is that we had to rethink. Our decoration rendering code used the QPixmap/X Pixmap relationship from the time when KWin only supported the native Qt graphicssystem. When we did the transition to raster the code did not get adjusted to the new world and that’s why we for example recommended the native graphicssystem for XRender. With the native system going away we just had to make it better and the improvements made for XRender benefit the OpenGL compositor in the same way. With Qt 5 I hope that we can get some further improvements for the QtQuick based window decorations. I was running KWin on XRender with raster and Plastik-QML as window decoration and was positively surprised: I couldn’t notice a difference in the speed compared to the OpenGL backend.

So how far are we with the transition to Qt 5? Last week I did a test compile against Qt 5 and KF 5. I hit a few issues but got it compiled. Apart from the known low-level issues (we still need some of the functions for Qt 4’s native graphicssystem) I only hit one compile issue with Qt 5 – given the source base that’s really a great job by the Trolls! In KF 5 I hit a few more issues – also because it’s not yet meant to be used. Well it doesn’t bother me much, I fixed the issues and started to integrate them either in KWin or in KF5.

But when it’s not yet supposed to be used, why am I investing time into it? The reason is the event filter. We need to transit our event filter from XLib to XCB and that’s something we can only test once we are running against Qt 5. I have some code prepared which at least compiles, though I know that it doesn’t cover everything and needs to be changed. I plan to give it a try over the next day, just to see how much breaks. But that’s the reason why we are doing it right now to have enough time till we do the final transition.

27 Replies to “An update on KWin on 5”

  1. “The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow. This change became possible because the screen edge related code was one of our strongest user of XLib and a refactoring was needed anyway to support the world after X. ”

    Is there possibility to change the distance of the corner/panel when glow is triggered? As now the panel glow trigger distance is way too short and it is more just a bullet in the feature list than visual feature. Like getting a setting to get max a 200-300px distance for trigger would make it much better visual aid.

    1. Not with X 🙂 It would be too much overhead to track a 200-300 pixel wide area. Once we are on Wayland it would be possible but I think it’s too large.

  2. ” But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid”

    So, that strange problem with this button, which sometimes appears on screen while changing desktops, after having used “present windows” could be just because of that?
    I’m thinking I should have filled that bug before 😛

          1. Yes, sorry, I misread the title. I though it was the bug that closed windows remained in Task Manager plasmoid.

            Thanks anyway 🙂

    2. no I think that’s unrelated. We have no idea for that bug (it is reported) and don’t know how to trigger.

  3. Using mouse hover events for triggering changes in GUI state is a hideous concept and does not translate to touch devices (unless you use Android on a S4 with it’s front facing camera) so please please try to enable alternate mouse button click detection for corner/edge related GUI state changes.

    1. screen edges are for mouse driven systems. If you use touch screen edges won’t be available.

      1. Whether screen edge detection is available on a touch device is besides the point, as far as I am concerned, activating GUI state changes via hovered mouse events is a completely broken and unusable paradigm. I, and the clients I support, have to disable all such behavior because the number of times it misfires and interferes with the users focus far out weights any possible convenience.

          1. Perhaps if the users you speak of had an alternative to hovering activations to compare with then they may prefer those alternatives. ATM it’s hover or nothing and every single person I know of, even on windows with the bottom panel, who has tried hovering events and thought it was neat to start with ended up disabling it.

              1. Being able to use all 3 mouse button clicks in the corners and edges to activate actions. Perhaps even in combination with meta keys but I don’t care about that. I want to specifically be able to use the RMB in each corner and edge to do what currently is done with just hovering the mouse pointer alone. Ie; move mouse to bottom edge, click RMB, and that raises the hidden panel and it stays visible until I specifically dismiss it with another RMB click.

                1. But clicking on the screen using LMB or RMB is already used for other things.

                  For example if you have a maximized window, moving the mouse to the top right screen corner and clicking the LMB closes that window.

                  Also, note that the current screen corner/edge activation does not respond to simple “hovering”, it responds to moving the mouse to the screen corner/edge followed by *pushing* it further in that direction. That’s not that different from your suggestion of moving it there followed by a click, except that it does not interfere with the normal click handling of windows and window decorations.

                2. > move mouse to bottom edge, click RMB, and that raises the hidden panel and it stays visible until I specifically dismiss it with another RMB click.

                  Wrong component, that’s plasma-desktop, not kwin.

                  You’re suggesting https://bugs.kde.org/show_bug.cgi?id=300008 and tbh, that bug is likely born out of the “i get my mouse out of sight by moving it out of the screen” disease which then likely stems from the MS world and is about the most stupid solution to a problem i can think of.

                  If you want to hide the mouse, just do that.

                  There’s the pretty dated “unclutter” and writing a tool that did this (for a complete different purpose so as side-effect) took me about 5 minutes (from “how does one do” to “mouse away”)

                  The proper solution is however to make the application where the mouse is in the way hide it.

                  If you worry about touchscreens: don’t.
                  When you push them in a random position you’ll get the required crossing events for free. What does not work in the kwin case is the pushback, which is however configurable.

                  Finally: you’re still free to deactivate all electric borders and place your click accepting windows there.
                  But here’s a good hint: if you allow random and pot. destructive actions by clicking into some invisible space, you’ll find yourself in trouble soon.

            2. “ATM it’s hover or nothing”

              What hover-triggered GUI changes do you mean, exactly?

              If you mean the blue glow, that isn’t really a feature in a functional sense, it’s a non-obtrusive and completely non-critical indicator, a.k.a. “eye-candy”. I don’t see why it should not be triggered by hovering.

              If you mean the sliding panels and the “Show Desktops” and “Show Windows” effects themselves, then your assertion that users aren’t given a choice in how to activate them is wrong.
              Panels can be set to ‘always visible’ (the default panel already is), and the desktop effects can be activated using keyboard shortcuts.

              For example, when I set up KDE for someone who uses a “multimedia mouse” with 7+ buttons, I tend to map the “Show Windows” effect to the lower thumb button (using xbindkeys + xte), that’s usually quite well received.
              But if such a mouse is not available, I personally don’t mind activating it through the screen corner, either.

              If you have a better idea than screen-corner-hovering that works with all keyboard/mouse combinations, please say so… 🙂

      2. Maybe it can be done by using a slide gesture from the screen edge (or angle) to the center of the screen (only valid as a touch gesture, not with the mouse of course)…

        PS: I know, like windows 8 :verysad:

  4. Replying to smls, the current replies are becoming unreadable.

    “But clicking on the screen using LMB or RMB is already used for other things.”

    Of course but there are 8 very special 1px areas in 4 corners and on 4 edges that are “global” to every desktop and easily calculated (ie; top-left is 0,0… done) and the Electric Borders(?) code would already cover this. All I am suggesting is that when the mouse pointer is a 0,0 that it does not activate anything (unless the user wants it to) until a mouse button click is ALSO registered and that event is then trapped. If trapping the mouse click event involves putting an extra invisible window above the whole desktop that does nothing except (optionally) trap mouse button clicks in the corners and edges then so be it.

    When I currently use hover to raise a panel, on any edge, it does not require a “push into” the edge to activate. Not that I can perceive anyway. The corners, yes, but very subtle and now that I use the Title Bar Button menu style on maximised apps I find the current top left screen edge mouse position detection (okay, “hovering” is not correct) simply misfires far too often to be useful (for me).

    a) if I could RMB (or LMB/MMB) in each corner then I would have far more precise control over when the action gets fired.

    b) if the available actions also included “Other”, such that I could define a command or dbus action as well as the current pre-defined options, then the number of possibilities and overall functionality of using edge/corner detection would be almost unlimited.

    1. “such that I could define a command or dbus action”

      You can already do this using the ‘xte’ tool from the ‘xautomation’ package[1], which most Linux distros should have in their repositories.

      For example, by default the “Present Windows (Current desktop)” KWin effect is mapped to the Control+F9 keyboard shortcut.

      Thus if you have the aforementioned package installed, you can also activate the effect by executing the following shell command:

      xte ‘keydown Control_L’ ‘key F9’ ‘keyup Control_L’

      You could execute this command from wherever you like, for example you could set up xbindkeys to automatically execute it when a special mouse button is pressed. Or you could script a simple Plasma applet with a button that executes the command. Or even try to implement your “invisible window” idea (even though I personally still think it would interfere with the normal functions of the left and right mouse button).
      As you said, it opens up many possibilities…

      —-
      [1] http://hoopajoo.net/projects/xautomation.html

  5. Thank you for great work on kwin!

    I am especially excited about the changes made in terms of qml (Desktop Grid, the screenshot you provided). Is it possible to compile and test those changes now?
    Could you point me to the source? I am afraid it involves recompiling plasma, right?

    Would be very thankful!

  6. Or, as I am a Opensuse user the KDE trunk repositories should already contain this fixes, as I suppose the mentioned changes have been merged.
    Please correct me if I am wrong!

  7. Great job Martin and partners, since I was discover KDE (not really a discover), I cant use any other desktop enviorment, they looks like stones, boxes and other ungraceful things. Thanks for all and keep doing this excenlent work. From Cuba, best regards.

Comments are closed.