Recently Aaron wrote a blog series for the introduction of Spark, I want to cite a central saying of one post:
I want the things which I help make to become opportunities for others in their turn to participate with their own voice, their own movement and their own passion.
If I reflect my own motivation for my work on KWin and especially the areas of work I decided to work on in the 4.9 cycle I see quite some parallels to the paragraph cited above. But personally I would phrase it slightly different:
I want to help others to do awesome.
This describes perfectly what I am currently working on. I no longer want to write fancy effects – in fact I stopped adding effects quite some time ago. I don’t want to extend KWin to be the window manager which incorporates all other window manager concepts no matter how useful they are – we stopped doing that as well.
But still I want that our users get the window manager they want. Whether it is fancy effects or a tiling window manager or new concepts for virtual desktops, KWin should be the base for it.
At the heart of all these efforts we have the scripting bindings. While we already had bindings since 4.6 they never really got used – this will change 🙂 But JavaScript bindings is just one part of the game, the other part is declarative, that is QML, bindings.
In 4.8 we already experimented with QML for the window switcher layouts to test whether QML fits our needs and I am very happy so far with it. But 4.8 does not yet include the possibility to really write own layouts. While it is possible to do so, there is no way to configure a custom one or even distribute this.
For 4.9 the installation of the window switcher has been adjusted to use the Plasma Package structure which makes it possible to install window switcher through the plasmapkg tool. But this is only part of it: plasmapkg has been extended to support any kind of scriptable KWin content, be it window switchers, KWin scripts or KWin effects written in JavaScript (decoration to be added soon).
For this KWin scripts follow also the Plasma Package structure which is quite awesome as it finally allows to dynamically enable/disable scripts through our KCM:
This dialog wants to tell me: “I want Get Hot New Stuff integration” to directly download new scripts from the Internet. And sure it does need that and this will be added for the 4.9 release.
The screenshot shows two scripts I’m currently working on – both will be shipped with KWin in 4.9. Videowall is a script which scales fullscreen video players over all attached screens to generate a video wall. This is the first script which actually replaces functionality from KWin core. KWin had the functionality to disable multiscreen support for fullscreen windows and that really cluttered both code and UI. And it just did not make any sense. There are just no valid usecases to have in general fullscreen windows span all screens, except for video walls. And that’s what we have here: a small KWin script to make an obsoleted functionality sane. We improved KWin for everyone by removing an difficult and confusing control module without taking away the functionality for expert users.
But even more interesting than the video wall is the other script. This is not a JavaScript based KWin script, but a declarative QML script. It will replace the existing C++ based implementation of the desktop change OSD without any functionality loss. Which means less code and much more readable code 🙂
And what’s really awesome: JavaScript and QML have the same bindings, the API is exactly the same. So going from QML to JavaScript and vice versa is extremely simple. But that’s not all with QML based KWin scripts you can include live window thumbnails. So this is a technology to allow you to do awesome new switchers like Present Windows or Desktop Grid.
As you notice I’m currently dogfooding the bindings to myself. This helps me to see what is needed, what can be improved and to ensure that the bindings will work for any given usecase we can imagine. My wish is to see for example the complete window tiling support in KWin to be rewritten as a KWin script. This should be possible and would proof that you can use scripting to get a completely different window management.
So if you want to make awesome things with your window manager, now is the time to get started. Don’t hesitate to contact me and demand further bindings if anything is missing.
Disclaimer: QML support has not yet been merged into master.
Dear Martin,
I find your work more than fantastic… It opens new horizons in kwin and helps many newcomers (programmers) to start participating in KDE development more actively… I ‘d like to point you in one idea I have published in KDE brainstorm (http://forum.kde.org/brainstorm.php?sid=5ea004fffd24f42a56097bc3edced5b8#idea98076_page1).
I have started my little effort creating a new qml plasmoid that is going to present the whole idea. But after your fantastic article I can see that there is a big possibility to be able to implement it in kwin qml scripting.
I am still far from presenting any beta of the plasmoid but I have hopes :).
One thing I dont know is if there is an engine for handling Virtual Desktops just like the Activitites one…
Thank you once more for your fantastic work….
thanks for the link. In fact that is exactly the feedback I wanted to get. It shows me that the current bindings for activities related functionality is not yet good enough 🙂 Virtual Desktops on the other hand are as good supported as possible.
Fist of all awesome work! Kwin just keeps getting better (and faster!) Now a question…
In the past it was stated that having different activities per virtual desktop wasn’t feasible for technical reasons.
Now I see that there is a nice activity switcher for Plasma Active kinda like the window flipping effect from Kwin proper.
Is there a chance now that a different activity per VD is possible, essentially allowing the user to merge their activities and VDs?
I would just like to rotate the cube to be at my next activity, without having to use the context menus.
Is QML a ‘magic bullet’ that someone (maybe even I) could use to implement an ‘Activity Cube/Wall’ effect
the technical limitations hold of course also for the scripted APIs. The problem is quite simple that we don’t have previews for other activities.
I see. So in the current system you can have several activities running at once but only see one visible on the desktop.
So an activity switcher in kwin will, not be possible. 🙁 Although there may be a hackable solution. Kwin knows the possition of the apps on each activity, and could get whatever wallpaper is on each activity, If you add them all together you could get something like a preview for an activity.
“But still I want that our users get the window manager they want. Whether it is fancy effects or a tiling window manager or new concepts for virtual desktops, KWin should be the base for it.”
I just wanted to write an email to the kwin-ml about how (and whether) to integrate the workspcestrap correctly into kde. Am I right assuming, that the correct way would be not to integrate it into kwin directly, but as a qml-kwin-script?
Another question: Will it be possible to integrate kwin-scripts and plasmoids (e.g. by accessing the kwin scripting API from a plasmoid)? For another experiment, I’m planning to implement using a kwin-script, I’d need to be able to access some functions of the script within a plasmoid.
If not, is there another possibility planned to control a script? Global shortcuts probably won’t be enough for many scripts…
Nice work 🙂
Yes I think the best way would be a QML script. What you did quite helped me as it showed what should be possible to do. You used an effect which is not the best solution as in fact what you wrote does not depend on compositing.
Integrating it into KWin core directly is probably also no good solution as it would most likely to be too much change.
No, Plasma and KWin are different processes. So Plasma cannot access KWin internals and vice versa.
I have not yet thought a lot about it. Most likely the scripts will be allowed to register global shortcuts, can read their own configuration and can be slightly controlled through D-Bus (enable/disable/reload).
“Yes I think the best way would be a QML script.”
ok, I’ll try to port it as soon as qml-support is merged and I find the time.
“No, Plasma and KWin are different processes. So Plasma cannot access KWin internals and vice versa.”
As you say it, it seems logical to me.
“I have not yet thought a lot about it. Most likely the scripts will be allowed to register global shortcuts, can read their own configuration and can be slightly controlled through D-Bus (enable/disable/reload).”
I would love to see some way to let the script register dbus-methods. What I would need is this: I want my script only to handle some windows and let the user control which ones (and also display which ones are being handled by the script) using a plasmoid. This is just possible, if the script and the plasmoid can somehow communicate, e.g. by using dbus.
PS: I’ve just had a look at the API-doc on techbase. Is there a certain reason, why client has a property skipSwitcher, but not skipTaskbar and skipPager?
from the very heart: thank you for enabling me doing awesome, martin, aaron, and everyone else at foss!
Nice work but one thing: as every foundation to build something it need to be solid, hope Kwin will receive love on most favorite things of many users: stability and performance? (not only on super duper new fast hardware but in not so old too). I know you must be tired of this comments but this are crucial things. Also I’m very glad that you’re done making another effects – there are far more important things to do (still it was great to hear that many of them are optimized for 4.9). Polishing things that we already have is what KDE needs.
– Humble user of KDE 🙂
Do you really think the KWin is slow an unstable. For me it didn’t crash probably since 4.2 and since 4.7 runs smoothly with compositing on three years old Intel onboard graphics – you can hardly get any worse hardware these days.
I didn’t say that kwin is crashy, in fact with every release it’s getting better, I just don’t want future development to be focused just on new futures and forgot the rest. >3 years old hardware is still nice hardware for web browsing, and many times linux is second chance to that hardware, it’s nice to hear about getting older things to work better, just couple days ago I’ve read about effects optimizations – that’s awesome, and not so long ago kwin team solved bugs that made shadows horrible broken on older graphics cards, that’s all I ask for – don’t forget that mamy users still use older but not-so-old hardware and there always are things that can be optimized 😉
We know that KWin is rock solid – most crashers we see are bugs in underlying technology. And from the feedback we get users are very pleased with the performance of 4.8. Optimizing for old hardware is unfortunately hardly possible anymore as for example my computer does no longer support AGP graphics cards.
Yeah I know, I’m also pleased because with every release is getting better and better and people like it more mostly because it runs faster on their hardware than previous release (not because it has gazillion new effects). We all admire devs work and I know that there is limit of hardware that you can support but improvements that I mentioned earlier are also appreciate
I almost thought you were going to say you’ve Duplicated the Awesome window manager in KWin. But with this I think one (read: not me) could. This is quite amazing.
Hah, same here. This should be the next script on the list just for the pun alone. 😉
@Martin:
Fantastic, thanks for your work and for blogging about it!
For someone not familiar with KWin’s internals and scripting in general it’s hard to imagine what’s possible to do, some more examples (maybe common feature requests?) would be much appreciated. 🙂
Personally I’m interested in the following:
1. Would it be possible to implement the current KWin tiling as a script?
2. Is it possible to get something like GNOME Shell’s workspaces, i.e., if all virtual desktops are full (have at least one window) add one desktop, if one desktop is empty remove it. It’s similar to your “Create Temporary Desktops For Applications” script but with different conditions.
both examples should be possible
That’s truly awesome (I tried hard to think of a better word but just couldn’t). I’ve always liked KWin for its many features but also had the feeling that it tried to be “too much”. This simplifies KWin while extending its functionality and lowering the entry barrier for new developers, can it get much better? 😀
This is awesome! I like software which just provides core functionality, but is extensible through plugins 🙂 (makes code more readable & problems easier to find :P) Also simple configuration options are a very welcome. Is there any difference in speed when you compare the JavaScript stuff against a pure C++ plugin? (not much, I guess, as the rendering is done by C++ code)
Have you started using Debian recently? (Iceweasel logo in second screenshot)
you got it right: rendering is done in C++ which makes it as fast as native code. My personal feeling is that the QML based views are faster than what I had before in C++ as I think QML handles painting smarter than my own code.
And no I have not switched to Debian recently – it has been several years ago 🙂
Cool! (I like seeing people use Debian ^^ Recent events in Ubuntu development moved my focus back to Debian too)
It’s interesting that scripted interfaces are now faster than C++ code… Proves the thesis that optimizations made automatically by the interpreter/underlying code are better than everything a programmer can think of when implementing it in C++.
I was *very* sceptical for using scripted languages on the desktop (experiences with Python code…), especially for time-critical stuff, but it looks like I’ve to rethink this position again ^^
Keep on making KWin even more awesome! It already is by far the most stable and functional window manager on all Linux desktops.
And add GHNS support to it and users can do “Get New Scripts” 🙂
This is really…. awesome. With KWin and Plasma being so modular, users and distributions would be able to create a whole different user experience than the default one.
I have a suggestion concerning the configuration UI. I think that the term “script”, while being technically correct, may not be easily understandable by users. It seems to me that scripts will be used to extend different aspects of KWin (effects, windows behaviour, virtual desktops…). Therefore, I think the management of these scripts should be integrated into the existing configuration UI for each category.
This might not be a big issue as this is targeted at power users, but having a clean UI is always better for discoverability. This also might require a lot of work, making it difficult to code for 4.9, but I think it would be a good thing to have in mind when designing the inner workings of it.
Keep on the good work on KWin !
Sorry for nitpicking:
I’m not a native English speaker, but isn’t “awesome” an adjective, and can’t be used like that ?
“do awesome stuff” would be ok, but “do awesome” sounds more awful to me 😉
Alex
no English speaker complained 🙂 That is I’m not sure whether it is correct or not.
From what I know (asked an American nearly the same question months ago), “to do awesome” is okay in colloquial English. it’s some kind of an abbreviation for “to do awesome stuff”.
Especially in OSS dev world, where just a minority is a native English speaker, my (personal) guideline is: “if everyone can understand the text somehow, it’s okay”, which is the case here 🙂
Please correct me if I’m wrong 😛
As Hans put it: It’s hard to imagine what’s possible do with that scripting.
Martin, you mentioned that it’s possible to write effects with it — would it be possible to write (a modified version of) the „show mouse cursor“ effect, i.e. paint something on the desktop depending on the location of the mouse pointer position with this JavaScript/QML framework or it this a completely different matter?
no, currently the JavaScript effects do not yet allow to render “random” things on the screen. That’s probably nothing we will see in 4.9. Maybe 4.10 material.
Martin,
You rock! Seriously, this is another awesome thing you made possible.
I do have 2 questions.
1. Where have you hidden this nice fancy stuff? Which branch? I can’t seem to find in kde-workspace.. Or did you mean that you made it, but haven’t pushed it to “any” public repository yet?
2. Provided you did push it to some public repository, how can i compile the latest KWin stuff in KDE 4.8? I kinda want to avoind recompiling all of KDE. Last time didn’t really end up good for my nerve system ^_-
Asking this because i would like to play with the QML part to for example show the Activity name when you switch activity and probably a few other things.
1. most of the code is mostly just published in review requests and the QML stuff is still just only on my hard disk.
2. Sorry, I cannot help there 🙂
Guess i just have to wait till you push it all to master 🙂
Did you know that you are Awesome?