QML saved KWin Scripting

Over the last half year I blogged several times that I would drop KWin’s scripting component if nobody takes over the development of the code. Unfortunately up to now we have not seen any improvements. So keeping to my words I would have to drop the code.

Instead I decided to do a last try to get some work done and created some Google Code-In tasks and thanks to that the Tutorial and API documentation got imported to techbase. Example scripts are ready to be imported into kde-examples repository and we have received a KCM for managing the scripts. This is what I consider the minimal requirements for keeping scripting. Without an API documentation it’s just useless.

At the same time I have started to do my planing for the next development cycle. The main task of my work will be in the area of QML (surprise, surprise) with the aim to drop all custom GraphicsView code in KWin and replace it by QML. These are:

  • Remaining clean-up of TabBox: Desktop Switching needs to be ported, old code needs to be dropped
  • Aurorae is completely GraphicsView based and should be possible to be ported to QML. It will not just be a port of the theme engine, but will allow to write decorations in general using QML. One of the QML based decorations will then be an Aurorae theme interpreter. The long term plan for this is to get it into a state that it can replace the existing decoration API. Will need some time and some work together with Thomas and Fredrik – our decoration experts in KWin. The long term goal is to have it ready for the scene graph in Qt 5 and hopefully be able to integrate this very well with our compositor.
  • Desktop Change OSD: rather simple. Help more than welcome :-)
  • Desktop Grid and Present Windows: our effects which use widgets. Now this is the really interesting part of my 4.9 work. Desktop Grid and Present Windows will be ported over to QML and won’t be effects in the classic sense any more. I have been dreaming for years about having effects in a state that our UX designers could do them without hacking C++. Finally we are at the state where this is possible :-) As a nice side effect that will make it possible to use Present Windows even without compositing – an idea Lubos told me at my first Akademy in 2008.

All those areas somehow have to access KWin Core and at the moment all have different approaches. Decorations use a “bridge” between the Client’s and their decorations and partially direct function calls.

Effects have an EffectsHandler and EffectsWindow interface representing the Core functionality and working as a proxy. So very similar to the decoration bridge but with much more functionality.

Scripting on the other hand uses a “Wrapper” to export JavaScript functions and calls then the underlying Core objects.

For QML we would have to add Properties to all the functionality which we want to have exported. Which would be the fourth technology and one to many.

Yesterday I started to add the Property definitions to our Client class and ported KWin scripting to use the properties instead of the Wrapper for Client. It breaks existing scripts, but works quite nicely so far :-) For me this brings scripting finally in the area where it becomes useable to me: an easy way to test my property definitions.

So we can expect that scripting will get quite some love over the next development cycle. It will be tailored towards my developer needs which will help everyone.

But not only that. Given that we now have the properties, we can also base our Effect system on them. And Thomas did some great work on a generic effect implementation. So expect a second JavaScript API to write effects :-)

Exiting times are before us simplifying our development work and getting KWin ready for the next big step.

As I expect this to be my last blog post before Christmas I wish everybody a Merry Christmas and relaxing holidays. Thanks for using KWin and all the support I got this year for my work :-)

15 thoughts on “QML saved KWin Scripting”

  1. great stuff
    but i was wondering what happend to project-60-frames?
    kde is still kind of slow on my desktop (nvidia-blob + deactivated oxygen animations) compared to my laptop (catalyst + activated oxygen animations)
    anyway
    frohes fest und guten rutsch

    1. we are always working on the project 60 frames. E.g. we currently have a pending review request to adjust the Qt graphicssystem towards what’s best for a chosen GPU.

      With NVIDIA we highly recommend to use the raster graphicssystem. More help in userbase

      1. im on chakra linux
        so raster should be the default
        but just in case: is there a way to see what backend is in use?

        1. Sorry, sent the previous comment by accident.

          The graphics system currently in use by Qt applications is usually governed by the environment variable QT_GRAPHICSSYSTEM. If it’s not set, it defaults to native, that in X11 means XRender.

          Martin, is this also true for KWin?
          I remember that I read somewhere Andreas saying that KWin calls QApplication::setGraphicsSystem(“native”).

          1. No, that system force has been removed with 4.7 – the pending review will allow you to chose the system explicitly as well as attempt a “sane” default setting (which is mostly avoiding the raster system on the XRender backend and possibly have a decoration suggestion, because some decorations heavily prefer the one or other graphicssystem)

  2. Frohe Festtage und ein gutes neues Jahr!

    Speaking about 4.9 plans: I remember your Blogpost about Wayland and such. What happened to those plans?

  3. Very nice to hear. I don’t use scripting myself, but improvements in theming and effects are always welcome.

    What about the maximize effects you get when dragging a window to the screen edge, and the peek effect when hovering over windows in the taskbar. I remember someone saying that there were plans to make those prettier. Would those also be candidates for conversion to QML?

  4. Seems like QML is the answer to everything. :D

    Can you write a few words about how this will affect the performance, in particular of the desktop effects? Using Present Windows without compositing would be very cool (as long as it’s not too sluggish). For example on Plasma Netbook, it is a rather important effect for the workflow, and having it behave consistently regardless if composite is enabled or not would rock!

    I hope this also means that we can get an elegant desktop effect for switching between activities.

Comments are closed.