Posted on

Looking for KWin Bug Triagers

At the moment all incoming KWin bugs are managed by the developer community. This is actually not a really good solution as we have a high count of duplicate crash reports and also many bugs where we have to ask again and again for the same things (e.g. providing driver information or providing the list of loaded effects). Obviously if developers spend time on managing the bugs they cannot fix bugs in this time.

KWin is in the very lucky situation to have a cleaned up bugtracker. This means we don’t have old junk in the tracker and our bugs are nicely categorized by being put into the right categories. So becoming a triager would not mean cleaning up the old stuff but only help us with incoming bug reports. And that are in fact not that many – we get about 20 new bug reports per week.

For us developers it would be really helpful to only get the final and real bugreports. That is reports which have a way how to reproduce the issue and all needed information to properly investigate an issue.

So your task as a bug triager for KWin would include:

  • Finding Duplicate crash reports (very easy as DrKonqui adds the number of possible duplicates)
  • Identifying clear driver crashes (relatively easy if you understand a little bit about reading backtraces)
  • Escalating if a driver crash is reported too often, so that we can consider adding a workaround
  • Adding meta-information to the report: version, component, flags
  • Verify that the bug is reproducable
  • Add the steps to reproduce a bug if it is missing
  • Identify actual user support issues and send the user to forum.kde.org
  • Discard all Wishlist reports and send user to brainstorm.forum.kde.org

As we currently read all reports and are used to work with the bugtracker we can provide help and you can start by just watching our work in the bugtracker by following the shared bugzilla user. If you have questions about why we for example set a bug to duplicate I’m happy to explain that and for that I would prefer using #kde-bugs on freenode.net so that many bug triagers can get the information.

We would be glad to welcome you as a KWin Bug Triager and your help to make KWin a better window manager will be highly appreciated.If you are interested please leave a note, send a mail to kwin@kde.org or just ping me in #kde-bugs.

Posted on

This week in KWin (2012, week 28)

I decided to start a new blog category called “This week in KWin”. Based on the bug reports we resolved in a given week I am able to highlight important developments in KWin. This is not meant as a replacement or competition to the Commit Digest – I am very happy with the digest. But it is for overall KDE and does not give us any possibility to add further comments to it or highlight very technical things which might be noteworthy (yes, there is the digest tag for commits).

The biggest difference to the commit digest is that this report is generated from the bug tracker while Commit Digest is generated from git log. I think the bug tracker is a better source to track the development of a project as quite often you have a commit series for a specific bug or feature.

Important Changes in week 28

This week we have seen the tagging and release of the last release candidate for 4.9. As you can see in the summary below we have fixed quite a few issues last minute on Monday. This includes two rather important fixes for the rendering of thumbnails and the logout effect is finally available again. These were changes mostly done on last day of Akademy and while flying home.

We had received a very interesting crash report for 4.9 (4.8 is not affected) which got fixed (not available yet in RC2). When you use an Aurorae theme and close a glxgears window through the close button, KWin crashes. We had such issues with the old Aurorae implementation and had thought the port to QML had finally solved it. So we added the same and already known workaround from the old implementation to delay the closing by one event cycle.

Last but not least there is one important change for the 4.10 release. KWin’s window tiling capabilities which were implemented by a Season of KDE project a few years ago had to be removed again as the feature is seeing some bit rot and is completely unmaintained. Thanks to scripting it should be possible to implement window tiling again and provide it in time for 4.10. And work is going on to make that happen. If you want to help, please leave a note 🙂

This change does not affect the upcoming 4.9 release and does not affect the quick tiling on screenedges functionality.

Summary

Crash Fixes

  • 179077: drag-and-drop between windows by cover switch alt-tab causes apps to crash
    This change will be available in version 4.10
    Git Commit
  • 303450: kwin glxgears crash
    This change will be available in version 4.9.0
    Git Commit

Bug Fixes

  • 296065: Lanczos Filter broken after screen size changes
    This change will be available in version 4.9 RC 2
    Git Commit
  • 297864: ThumbnailItem allows upscaling of Windows
    This change will be available in version 4.9 RC 2
    Git Commit
  • 302164: the efficiency of drawing in kwin 4.9 beta2 is lower than 4.8
  • 303096: Logout effect completely broken
    This change will be available in version 4.9 RC 2
    Git Commit
  • 303200: Incorrect signal connects for activities in WorkspaceWrapper
    This change will be available in version 4.9 RC 2
    Git Commit

New Features

    Tasks

    • 303090: Remove Tiling Support From KWin
      This change will be available in version 4.10
      Git Commit
    Posted on

    Akademy Impressions

    Now that I am back home I finally find some time to blog about my impressions of Akademy this year. Overall it was a really great Akademy at an awesome location and wonderfully organized by the local team. Thanks a lot for your work!

    For me it was the already the fifth Akademy – I hadn’t realize that before and was quite surprised, I still remember my first Akademy in Mechelen as it were yesterday. This year Akademy was a very special one as I had been a member of the jury for the Akademy Awards. I am very happy with the people and products we awarded this year. Camilla, Lydia, Kevin and Nicolás all do an awesome job in their area and all help shaping the future of KDE.

    From a conference point of view my personal highlights were the talks about Qt 5 and Frameworks 5 (thanks to Thiago, Kevin and David) as well as Mirko’s talk and the talk about defensive publications. I’ll probably start to document some of the “innovations” inside KWin soon (personally I do not consider anything inside KWin being an innovation, but I see that we should have it published before someone gets a patent on what we did years ago).

    My highlight of the days after the conference is the training on QtQuick 2 by our friends from KDAB. I was afraid that I would not learn anything new, but there was lots I did not know and I realized how I can improve my QML code quite a bit. Some of that (especially based on feedback from Nuno) already made it into the 4.9 release. But maybe most important is that I got an idea how QML based effects could look like which could contain shader elements as will be available in QtQuick 2.

    While nothing is implemented yet I thought about how our Fade effect could look like in QML:

    WindowEffect {
    id: myWindow
    opacity: 0.0
    onClosed: opacity = 0.0
    Component.onCompleted: myWindow.opacity = 1.0
    Behavior on opacity {
        NumberAnimation { duration: 150 }
    }
}

    Well we will see how this idea will evolve.

    Another highlight of the days after the conference was a session where Jeroen van Meeuwen was present and explained his plans for our bugtracker. I am very glad that there is someone who cares and wants to help us getting bugs.kde.org in a usable shape again. I am really looking forward to this happening and I hope that our developers will support his efforts and start using the bugtracker. I am convinced that bugzilla is our most important and most neglected piece of architecture and a proper usage will help us producing better products (and with that I don’t mean that we fix bugs).

    Of course I hardly did any coding, but I mentored a BoF where I explained a little bit about the internals of KWin. I hope to see some patches and that is more important than me coding. But I fixed a few bugs I found by pure chance. And I must say this makes me rather unhappy. If a functionality is broken for almost a year and it’s me noticing then something is really broken. That I don’t use the functionality, that’s just fine. But that no user noticed that the logout effect has not been working at all in 4.8 is quite shocking.

    So please my dear users: if you see some “obvious” bug where you think it must have already been reported, please report it nevertheless. Not each obvious bug might be obvious to the developers (I only suspend my system and over the last year got only logged-out by a freezing BLOB). I rather have a duplicate too many than a broken feature.

    That reminds me: we currently have a release candidate out. Get it, test it!

    Posted on

    Workspace Sprint

    The last week I was allowed to spend in Pineda de Mar for the Workspace sprint. As others have already pointed out it was quite a different sprint with not much hacking going on and not so much technical discussions into the details. For this we will have a Tokamak sprint in Randa later this year.

    Our sprint was mostly focused on community building and getting everyone on the same knowledge level. The weeks leading to the sprint showed that this was needed and I myself – although being involved in Plasma for quite some time – had to catch up on many things I was not aware of. The sprint helped us to identify for example weak spots in our internal documentation and getting this fixed is now one of the highest priorities.

    The games Kevin played with us really helped us to identify where we want to go and what that means for our future development. This will also influence KWin’s development as we finally understand how Activities and Desktops go together and that helps us in KWin to properly focus development effort on it. Over the last cycles we did not really work on activities support in KWin as we were very unsure on how the window manager is involved in the process. This is now much clearer to me – I just need to document it and luckily Aurélien already started that process.

    Luckily I was able to also get some hacking done. As Mr Gwenview was sitting next to me, I started to add some OpenGL magic to the image viewer. Sometimes I just need to work on a different piece of code and to get away from the daily work on KWin. The result is a much smoother zooming experience. At the moment the feature set is not yet identical to the existing implementation, but it’s on a very promising way. Very pleasing is also that at least on my system it works also well with llvmpipe, which could be a very nice solution for the case that a user does not have a decent OpenGL graphics card. For users who like to experiment, feel free to give a try to graesslin/opengl branch in the gwenview repository.

    Overall it was a very nice sprint, but also very exhausting. I’m glad that I have one day to relax before going back to work. And I am really glad to see everyone again at this years Akademy where I will give a talk about KWin scripting.

    Please thank the Frankfurt Airport for this blog post. Thanks to needing more than forty minutes to get my luggage from the plane to the belt I missed one train by two minutes (it went > 1h after landing) with the next train only after one hour instead of the normal half hourly service.

    Posted on

    Unit Testing a Window Manager

    KWin is one of the oldest KDE applications still in active development without having been rewritten from scratch. Development of KWin started in 1999 for KDE 2, but some parts of KWin even date back to KWM from KDE 1 times. The main software design of the Window Manager component hasn’t changed that much since the initial commit – there is a “Workspace” which manages “Clients”.

    Personally I find it very interesting to see such old parts of the code and software design. If we think about it we realize that the development started just a few years after the Gang of Four published their book about Design Patterns. Also development-methods like Test-Driven-Development and unit testing got described around that time for the first time.

    Given that it is not surprising that when development to KWin started unit tests were not added to the code base. At the time when QtTestLib got introduced KWin had already been in development for six years and not necessarily a code base which could easily be unit tested. Some classes inside KWin had turned into a size which makes it hardly possible to mock the required functionality.

    In order to use QtTestLib the port to Qt 4 had been required. At the same time compositing support got added to KWin – an area which mostly depends on visual representation and which is hardly unit testable at all. It is quite understandable that at that time nobody considered it worth the effort to add unit tests to the existing code base.

    Also it’s quite difficult to start with unit testing if you have been developing an application for a decade without unit tests. You might not see the need for the tests and in general we can say that adding the first test is the most difficult. For an application like KWin which highly requires interaction with an external application (X-Server) it is quite clear that one might consider it as impossible to unit test KWin at all.

    Personally I believe in the usefulness of unit tests especially during bug fixing. So I think that each bug fix should come with a unit test illustrating the problem. Unfortunately there is still a long way to go before establishing such a policy in KWin due to the difficulties in performing unit tests for a window manager.

    Nevertheless even KWin has parts which can be unit tested. And recently I added the very first test to KWin. In 4.8 the KConfig Update Script had a small bug which resulted in very rare cases in an incorrectly migrated configuration. When adding the KConfig Update Script for 4.9 I wanted to make sure that all possible upgrade paths are considered and therefore added the very first unit test for the KConfig Update Script.

    With that the most important first step is done: the KWin source tree contains a tests directory and now it becomes easier to add further QtTestLib based tests. So when I recently started to refactor some code which can be unit tested I decided to go for adding a unit test together with the new implementation. And I must say it turned very useful – some minor bugs I added, could be easily spotted without any code investigations. Just the way I like it.

    Unfortunately unit testing with QtTestLib allows only to test a very small portion of KWin. Anything interacting with the X-Server cannot be tested that way. Many parts require to be a window manager and as the situation is you can only have one window manager running. So a unit test would need to be a window manager and would interfere with the working system – nothing we want from a unit test.

    Given that we would have to basically start the full-blown KWin to perform tests which interact with the X-Server. Unit tests are out of scope and only integration tests seem feasible. But in fact running tests against a running KWin cannot work as it would interact with the running system. E.g. how to test that a window is set to keep above if there is a window rule that forces the same window to keep below.

    This is a difficult topic to solve. We basically need a dedicated testing framework which starts a (nested) X-Server, starts KWin, performs a test and shuts down both KWin and the X-Server. A framework which is decoupled from the running system.

    I’m currently supervising a Bachelor Thesis to evaluate the possibilities of such a framework and to implement a prototype tailored towards the needs of KWin. The current ideas look very promising and are based on KWin’s scripting capabilities by injecting KWin scripts to test certain functionality. I’m looking forward to this implementation as I hope that it will make our life easier – even if it will not be possible to run the tests on a Jenkins installation.

    Also I really like the idea of working together with students. We already do that during GSoC, but there are so much more possibilities for FLOSS to work together with academics. Being it Bachelor Thesis or just seminar papers: FLOSS source code is a great area to work together with real world software and not just a demo application as it is so often the case at Universities.

    Posted on

    Motor Tuning

    Mittlerweile hat das KDE Release Team begonnen die Quellcode-Pakete für die KDE Applications, KDE Workspaces and KDE Platform in Version 4.9 vorzubereiten, was für mich mal wieder ein guter Zeitpunkt ist zurückzuschauen auf das letzte halbe Entwicklungsjahr im KDE Plasma Fenstermanager und Compositor KWin.

    Für den Nutzer wird es in KWin 4.9 nicht viel Neues zu sehen geben. An einigen Stellen haben wir die Benutzbarkeit etwas erhöht, so zum Beispield das Konfigurationsmodul für Fensterwechseln komplett überarbeitet und das Konfigurationsmodul für Fensterdekorationen ist nun interaktiver geworden.

    Dies war aber auch nur möglich durch einige Arbeiten unter der Haube. Die Fensterdekorationsengine Aurorae wurde mittels QtQuick neugeschrieben, ist dadurch bedeutend wartbarer und performanter geworden und ist nun zumindest auf meinen Systemen performanter als unsere Standarddekoration Oxygen. Als Nebeneffekt kann der Quellcode auch in dem Konfigurationsmodul verwendet werden, was die nun existierende Interaktion erst ermöglicht.

    Aber nicht nur der Motor der Aurorae Themes wurde getuned, nein der ganze Fenstermanager musste an sich Anpassungen ergehen lassen. Der Startvorgang ist deutlich beschleunigt, vieles wird nun parallel abgearbeitet und generell wird nicht mehr so viel gewartet um zum Beispiel eine Konfigurationsdatei einzulesen. Das dürfte je nach Hardware den Startvorgang des KDE Plasma Desktops um ein paar hundert Millisekunden beschleunigen.

    Durch die generellen Umbaumassnahmen am Motor waren wir auch in der Lage einige richtig alten Bugs zu beheben. So ist der zweite Bug Report, den ich für KWin als Entwickler aufgemacht habe, nun endlich behoben: Fenster werden nach dem Schließen nicht mehr über andere Fenster gesetzt sondern behalten ihre Position. Was eigentlich nur nach einem Schönheitsfehler klingt, ist durchaus auch relevant für die Sicherheit. Durch diesen Bug wurden Benachrichtigungen für ein paar Millisekunden über der Bildschirmsperre angezeigt. Leider ist die Änderung doch sehr tiefgreifend und bringt den Motor noch etwas zum “stottern”, daher können wir die Änderung nicht in 4.8 einarbeiten. Bis zur Veröffentlichung von 4.9 bekommen wir das Stottern aber noch in den Griff. Gerade eben hatte ich einen Crash dadurch, fünf Minuten später war der Review Request mit dem Fix bereits erstellt.

    Auch in anderen Bereichen haben wir daran gearbeitet, dass der Motor einfach runder läuft. So wurden die “Fenstertabs”, also die Funktionalität mehrere Fenster in einer Fensterdekoration zu haben, komplett neu geschrieben um die Stabilität zu erhöhen. Dies war ursprünglich einmal ein Google Summer of Code Projekt gewesen und wurde leider nach Abschluss des Projekts vom Studenten nicht weitergepflegt.

    Auch ein anderes Google Summer of Code Projekt wurde in diesem Release Zyklus neu geschrieben und ausgebaut: Scripting. In 4.9 können nun Skripte entweder als JavaScript oder als QtQuick geschrieben werden und wir machen davon durchaus Gebrauch. Die Anzeige, wenn der Desktop gewechselt wird, wurde durch ein QtQuick Skript ersetzt und einige Anpassungen zum Deaktivieren der Multi-Monitor-Unterstützung haben wir in Skripte ausgelagert.

    Skripte können nun auch bedeutend einfacher erstellt werden, nämlich über die Window Skripting Console, zu starten über KRunner (Alt+F2) und dann “wm console”. Der JavaScript Code wird direkt im Fenstermanager ausgeführt und ermöglicht somit ein sehr einfaches Ausprobieren der Skripte.

    Ein zusätzliches Highlight ist, dass man nun Desktop Effekte in JavaScript implementieren kann. Ein paar Effekte haben wir damit auch bereits ersetzt und einige hundert Zeilen C++ Code durch ein paar JavaScript Zeilen ausgetauscht. Interessant ist, dass dies keinerlei Auswirkung auf die Performance hat, denn zum eigentlichen Zeichnen und Animieren wird weiterhin ein ausgereiftes C++ Backend verwendet. Ausschließlich Code zum Starten der Animation ist in JavaScript geschrieben.

    Zusammengefasst denke ich, dass unsere Nutzer sehr zufrieden mit diesem Release sein werden und uns nachsehen werden, dass es keine neuen Spielereien gibt. Dafür haben wir aber die Grundlagen gelegt, dass unsere Nutzer selbst mittels JavaScript und QtQuick neue Spielereien nachreichen können. Mein Vortrag auf der diesjährigen Akademy wird sich um genau dieses Thema drehen.

    Wer die Entwicklungen der KDE Community finanziell unterstützen will, kann zum Beispiel bei Join the Game teilnehmen. Für die KDE Community ist solch eine Unterstützung unglaublich wichtig, da wir Server zu bezahlen haben und wir das Geld einsetzen können um Entwickler zu den Sprints zu fliegen. Gerade die Entwicklersprints sind unglaublich hilfreich für die Entwicklung der Software, da hier die Entwickler die Möglichkeit haben mal direkt miteinander zu sprechen als immer nur über E-Mail oder IRC.

    Posted on

    Improving KWin Startup Performance

    I haven’t been blogging about KWin for quite some time, so it’s way time to write what I recently worked on for KWin.

    The big topic of the work of the last two weeks is improving the startup experience of KWin. It’s mostly a scratch your own itch as I do restart KWin quite often while working on it and having it start up faster is a nice thing in general.

    KWin consists of multiple parts which need to startup:

    • Window Manager
    • Compositor
    • Effects
    • Scripts

    The current version does everything in one go and starts with the compositor, but the first frame is rendered after everything has been set up. During this process the screen is frozen as the compositor has taken over the rendering from X and the screen has not yet been rendered by the compositor. This is not visible for users as KWin only starts up while the Splash Screen is shown and given the way how our Splash works this short freeze is hardly visible. If you know that it has to happen and if you know which of the shown icons belongs to the window manager you can see it.

    My idea to improve this is splitting up the startup into phases and try to get the first frame rendered faster. E.g. the Compositor is fully functional without Effects, the Window Manager does not need the scripts and so on. What we now already have in master is delaying the loading of Scripts into the first event cycle after the Window Manager has set up everything else.

    This does not shorten the startup time but reduced the frozen time. Even the overall frozen time is more or less the same, but we get a rendered frame in between.

    To get the actual startup time down a possible solution is to identify areas which take long and make them load in parallel. For that areas where KWin actually waits for something else need to be identified and moved into an async running thread.

    One of these areas is the loading of the configuration options. KWin re-parses the configuration file at startup. This is I/O and KWin needs to wait for it, but no longer in current master. The I/O operation is now performed in a background thread and only if the loading has not finished before KWin needs to access a configuration value for the first time it will have to wait. On my system loading the file takes only a few milliseconds and with an SSD it should be even faster, but nevertheless it’s a few milliseconds shorter startup time. And we have to consider that during startup there is a lot I/O going on and the file has probably not yet moved into the cache. But the longer it takes the more likely it is that KWin has to wait as we need config options very early in the startup process.

    Also the Compositor is currently waiting: it invokes an external program to figure out whether direct rendering is supported or not. After reworking the patches multiple times during review this is now strongly improved. KWin does no longer have to wait for the external program and as a side effect the code got cleaned up, so that no OpenGL call is created outside the compositor. To achieve the we “had to” remove OpenGL detection from the Desktop Effects configuration module. It now queries KWin directly which is of course much better.

    Executing the external program took around 100 msec on my system and the code which got removed were another 50 msec. That was about 5 % of the overall KWin startup time on my system.

    While doing the profiling I also figured out a few things which can easily improved when creating and destroying windows. So I discovered that the window decorations are actually created twice: once when the window is started for compositing and once when the window is fully managed by the window manager. This had been required to support both compositing and non-compositing and to allow easily turning on and off compositing at runtime (decoration needs to be recreated to e.g. remove shadows). My current patches will now ensure that the decoration is not created twice when a window is opened, though in the special case when kwin restarts it still has to create them twice. But that’s a problem I have to live with and which does not affect our users.

    Another interesting thing we discovered due to a crash I recently introduced: while ending the window manager completely we performed quite some heavy operations on the windows, which make sense during the normal operation but not when shutting down. This is now nicely optimized away resulting in a faster and more secure shutdown.

    This weekend I continued to move I/O operations into threads and loading KWin scripts from file does no longer block the window manager and compositor. It’s now more or less a pattern which I will try to use for other areas where files are loaded (e.g. some effects).

    Posted on

    Less Than 200 Open KWin Bug Reports

    After weeks of hard work by Thomas and myself the open bug count of KWin is finally below 200!

    This is best seen in the graph plotting open bugs over time. In the weekly bug summary you now have to select the top 50 products to see KWin at all.

    How did we achieve this great result? We have many user support issues in the bug tracker and many users don’t answer questions any more. Those bugs can be closed if the last comment is a year ago asking to provide the requested information.

    Many bugs have in fact been fixed since the bug has been reported and we just have not known that there is a report for this issue. Also many bugs are just for so outdated versions (4.2 or earlier) that any information provided in the report is no longer valid. Not only KWin has improved a lot but most important also the drivers.

    But there is still much more work to do in the bug tracker. 200 open reports is still much more than the number of real bugs which I expect to be below 100. So give us a helping hand. Reading an open report and trying to reproduce it is not that difficult 🙂

    Posted on

    A more elegant KDE Plasma Window Manager and Compositor

    Recently I have spent some time to make our window manager even more elegant. That is I decided to fix a few rough edges in our user experience offerings. All of these issues had actually been reported in our bugtracker as feature requests some time ago and listed as Junior Jobs, on the KWin ideas Wiki page and of course recently been added to the 4.9 milestone plan.

    Unfortunately nobody wanted to work on these important yet easy to fix issues 🙁 So instead of waiting even longer I started to tackle the issues myself to ensure they will hit the next release. That means I invite all readers to participate in the development: it’s really easy and we are quite open and offer help to new developers 🙂 We even have quite some non-development tasks like requesting new categories on kde-look/apps.

    The context menu when right clicking a window decoration has been synchronized as far as possible with the one of the tasks applets. Unfortunately we cannot share the code for technical reasons and some actions just cannot be available in both. E.g. creating a launcher doesn’t make sense in KWin and e.g. window tabs are a KWin internal functionality not yet available to Plasma Desktop.

    While I was working on the menu I also decided to improve the “Move To Desktop” menu by using radio buttons instead of check boxes. A window is either on one desktop or on all – the checks do not make any sense as the actions are mutual exclusive. This indication is important as for Activities a window can be on a set of Activities and there check boxes make sense and are used.

    Those users knowing the menu will notice that the entry “Configure Window Behavior” is no longer present in the screenshot. The entry has never opened any settings to configure the behavior of the selected window, which is quite confusing. It is in fact a quite exposed entry to the window manager settings. Based on feedback we got, including me asking non-technical persons what they expect this entry does, it got moved into the “More Actions” submenu and renamed to “Window Manager Settings” which is more compliant with other settings of our desktop shell like “Desktop Settings” or “Application Launcher Settings”.

    Another area which received a few more improvements is again the Window Switchers. In addition to what I wrote last week cursor key navigation got added to our fancy switchers like CoverSwitch. So you now have a consistent behavior no matter if you use an effect or a QtQuick based layout.

    In case there are no open windows when the Window Switcher is opened we now include the entry to “Show Desktop”. Defining the behavior for the Window Switcher when there is no window present is not trivial. The correct way would be to not show the list at all, but this would imply that there is no visual feedback at all to the user action. Also it is always possible that the last open window closes while the switcher is present. To handle such cases correctly we have so far shown a special text that there are no windows. But this has never felt very integrated as e.g. the thumbnail list is empty.

    By adding the “Show Desktop” entry we have a consistent and correct behavior as the desktop will be shown after the user ended Window Switching. Another improvement in this area is that the wording is now the same in all layouts and effects. The effects used to call this entry “plasma-desktop”. Also as the icon we now use the same icon as e.g. the “Show Desktop” Applet which you can add to your panel instead of the Plasma icon. So all together some nice improvements to have an overall more elegant user experience in the KDE Plasma Workspaces.

    Posted on

    Window Switcher Love

    One of my favorite features in KWin is Window Switching (aka Alt+Tab) and it is not surprising that it’s also one of the areas I prefer to work on and love to see others working on.

    This week our Window Switchers have received quite some love from various contributors. The compact layout got some usability improvements and the highlight in all layouts does no longer move around when pressing Alt+Tab for the first time. Navigation with cursor keys when the list of windows is open, is properly supported, now. That is in a horizontal layout the left/right keys can be used to navigate through the list, in a vertical the up/down keys are supported and in a grid all keys are supported. Of course the normal navigation is still Alt+Tab/Alt+Shift+Tab – navigation through cursor keys is just an additional useful feature for those who want to use it.

    Speaking of grid based layouts: I implemented a new QML layout in a “Present Windows” style. It is a layout showing thumbnails of all windows in the list in a regular grid and taking the complete available screen estate. By that it is similar to the previous Alt+Tab mode inside the Present Windows Effect. The code related to Alt+Tab has been removed from the effect, but otherwise the effect is of course unchanged.

    Having this mode as a QML layout has quite some advantages. E.g. it is no longer required to have desktop effects enabled, though it is still recommended 🙂 The layout follows the visual style of our primary Desktop Shell which makes it easier to use. Selection is indicated by the well known selection marker of the Desktop Shell Themeing. Last but not least the layout properly supports multiple screens, which has not been a pleasant experience with the old effect based implementation.

    Overall the new grid layout is also incorporating some of the feedback we received for the new layouts introduced in 4.8. Our default layout replaced the BoxSwitch effect, but there has been a slight difference in behavior. The layout makes only use of the horizontal space and by that thumbnails can become so small that they cannot be recognized any more. In the new QML based layout the thumbnails always have the same size at the compromise that some of them are perhaps not visible.

    A grid based layout provides here quite some advantages as the screen estate is used in a more efficient way to render high quality and good looking thumbnails even with a large amount of windows.

    I like to remember that we are currently selecting ideas on how to improve our default settings and switching to the grid based layout may be one of those. Also I want to remember that all those changes are rather trivial and could easily be implemented by new contributors and are also listed in our ideas page and as milestones for 4.9.