Posted on

This Week in KWin (2012, week 30)

The major event of this week was of course the tagging of 4.9.0. We have two important fixes which made it into 4.9 and apart from that not much happened. My current work on Aurorae is not yet finished and has not been pushed yet. The work on it also discovered two small regressions in Aurorae 3 and I’m quite unhappy that we will ship 4.9 now with two known regressions. But they will of course be fixed for 4.9.1.

I want to use this rather quiet week to remember everybody about the importance of reporting issues early. We got today a bug report where the user mentions that he noticed this issue already with 4.7 and 4.8. Well by know it was already fixed in 4.9 and the user is unhappy that he does not benefit from the fix as he uses Debian Testing (which won’t go to 4.9 any time soon). If an issue gets reported when it got introduced more users will benefit from the fix and it’s much easier to fix the bug as it is more likely that we remember what we worked on.

Please report bugs only in English language. This week 2 of the 18 reported bugs were not in English. This makes it much more difficult to handle the bugs as there is a language barrier. For me even a bug report in German is completely useless. I use my software only in English and have problems with back translating the German translation to English.

Summary

Crash Fixes

  • 304026: KCM crashes on updating a deco’s settings because the lib is conditionally unloaded in new ::canLoad()
    This change will be available in version 4.9.0
    Git Commit

Bug Fixes

  • 303937: Quick tiling (snap) uses wrong geometry on alternate attempts.
    This change will be available in version 4.9.0
    Git Commit

New Features

    Tasks

      Posted on

      QML Support for Window Decorations

      Implementing a new window decoration for KWin is not the easiest thing to do. While the API has hardly changed since early 3.x releases it is not very Qt like and requires a strong understanding of how the window decoration in KWin works. To design a window decoration you basically have three options which come with KWin:

      • Subclass KDecoration
      • Subclass KCommonDecoration
      • Design an Aurorae theme

      KDecoration gives a developer the most powerful options. The developer can design the decoration in whatever way he likes. But it also means that the developer has to take care about everything himself. E.g. properly laying out the buttons, handling mouse events on the decoration, ensuring the right resize handles are shown, etc. etc.

      An easier way is to implement KCommonDecoration which already implements the common aspects of a decoration. For example a normal decoration has some buttons on the left and some buttons on the right side. The main task of a developer is to define how large various parts of the decoration should be, e.g. the margin between the left buttons and the caption. This of course limits the possibilities with the decoration.

      The third option is to design an Aurorae theme which means just creating a few SVG elements. This is of course for designers the best option, but again very limiting. If a feature is not provided by the theme engine it cannot be represented. In the same way there are third party deKorator themes available.

      The C++ based decoration APIs seem to be too difficult to be used. If we look at kde-look we see that there are just 14 native decorations available and some of them are forks or old versions of decorations available in KWin directly. But there are already 79 Aurorae themes available and more than 150 deKorator themes.

      What seems to be a real issue concerning 3rd party usage can be validated if we just look into the KWin source base. In 4.9 we ship four window decorations: the Aurorae theme engine, Oxygen, Plastik, b2 and Laptop. Together they are 10 kSLOC of C++ code and 1 kSLOC QML code (Aurorae). Before Aurorae got ported to QML the size of the decorations was 13 kSLOC. Overall that is about 10 per cent of the KWin source base, which is rather large.

      When I ported Aurorae to QML one of the nice results was that I had to add a QProperty based API to communicate with QML in the first place. If this were the actual API writing a window decoration would be probably much easier. As a first step in that direction I started adding generic QML support to Aurorae.

      Following the general direction of all scriptable elements in KWin I decided to go for the well known Plasma Package structure, and added support to Aurorae to use a QML file from a package instead of the own QML file. The patch for this had been in my workspace for quite some time but I did not have any code to actually test whether it works.

      So yesterday I started to re-implement one of our C++ based decorations in QML. I decided for Plastik as the decoration is in fact broken and had been scheduled for removal. We have not yet removed it as we acknowledge the user’s wish to have the KDE 3 look still around. But we are unhappy with having a decoration which is broken and unmaintained. So having a QML replacement would be something rather nice.

      After one and a half days of work I’m proud to say that writing decorations in QML is possible. The changes to the configuration module and Aurorae itself are already under code review, the new Plastik still needs some love. But the decoration is already completely useable as can be seen in this screen shot:

      In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements.

      Overall the new QML API will provide the same powerful features as the KDecoration API, but also provides convenience functionality as KCommonDecoration, e.g. a button group taking care of laying out the decoration buttons. To make development of QML based decorations quite simple support is currently being added to Plasmate as part of the Google Summer of Code project. So you will be able to design and also test the decoration directly from inside Plasmate. This is also quite some improvement as with C++ the only way to test a decoration is to use it in KWin, which can be quite nasty during development.

      The API will need some more love till I’m quite confident to provide it’s usage but there is enough time till 4.10 🙂 So I hope that we can provide a better decoration experience in 4.10. I have a few ideas concerning the usage of QML based decorations in KWin and are looking forward to experiment with them.

      Posted on

      This week in KWin (2012, week 29)

      This week has not seen much development given that we are very close to the 4.9 final tagging. I pushed a little bit of refactoring into master (coming with unit tests), but apart from that we only had bug and crash fixes for 4.9.0 and even one regression in current master (4.10) got spotted and fixed. Thanks to Michael Pyne for bisecting and identifying the commit shortly after the commit had been pushed.

      I’m personally very unhappy to see bug reports being opened for new issues in 4.9 even after RC 2 as it means that the previous beta versions have not been tested properly. None of the reported issues is a regression compared to the previous beta and rc releases, so they should have been spotted before. At this I also want to remind to report “obvious” bugs which you think someone had to have noticed. E.g. the fade effect incorrectly faded in a minimized window which got closed resulting in a flash with the window visible again. It’s a very obvious bug but might not be spotted by developers (e.g. I never close minimized windows). Interestingly this bug had been present since a long time but had been shadowed by another bug which got fixed in 4.9.

      There has been one for me very interesting crash report which I cannot reproduce, but looking at the code the crash had been obvious and took me something like two minutes to fix. But as I don’t like pushing changes I cannot verify I wrote the first unit test which highlights an issue and verifies that the problem is fixed. In this case it was possible to write a test as the affected code is in the window switching framework which is seprated from KWin core and allows to mock the required objects. Nevertheless I had to introduce around 500 lines of mocking code to write a five lines test for a three lines change. Nevertheless it’s worth the effort as the next spotted bug in this area can be easily verified by a test.

      What I’m very happy concerning the bug reports is that none of the bugs reported this week are still open. All reports have changed the state to either resolved or needsinfo. For a relaese candidate phase that’s pretty good, but still we are looking for people wanting to help with triaging the bugs.

      Summary

      Crash Fixes

      • 303247: Crash after installed a new decoration
        This change will be available in version 4.9.0
        Git Commit
      • 303713: kwin crash when adding applets into the main amarok window
        This change will be available in version 4.9.0
        Git Commit
      • 303840: Kwin crash to do with hidden, empty or otherwise odd window titles
        This change will be available in version 4.9.0
        Git Commit

      Bug Fixes

      • 303397: KDE desktop effects are laggy when i uncheck Vsync option in system settings
        This change will be available in version 4.9.0
        Git Commit
      • 303579: Rapid flickering in locked screen — makes it difficult to unlock
        This change will be available in version 4.10
        Git Commit
      • 303891: Fade effect is being executed for minimized windows
        This change will be available in version 4.9.0
        Git Commit
      • 303630: kde-workspace fails to compile, see kde-core-devel post in URL
        This change will be available in version 4.9.0
        Git Commit

      New Features

        Tasks

        • 303314: Refactor Screen/Window PaintData
          This change will be available in version 4.10
          Git Commit
        • 303093: Don’t use OpenGL matrix stack in OpenGL 2 backend
          This change will be available in version 4.10
          Git Commit
        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

          Do not use BleachBit

          This week we received two crash reports after a user tried BleachBit. Reason enough to write a word of warning about this application.

          BleachBit invalidates shared memory included our shared data cashes. Any KDE application using will crash once the memory got invalidated. As to my knowledge Oxygen is a heavy user of the shared data cache any GUI application is affected.

          If you think that you need to use BleachBit I recommend to read the wonderful article on lwn about it: BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner? If you don’t know what it is, just forget about it, but warn anyone who you will see using it.

          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.