KWin’s userbase is quite diverse. We have users being in the range from the absolute Computer beginner to the Kernel hacker. Such a diverese user base can be quite challenging for the development. On the one hand you need to keep the UI as simple as possible so that even not so experienced users can use the computer without problems. On the other hand you should not dumb down the application to not upset your very vocal Kernel hackers. There is always the tempation to have the user interface too complex given that one as a developer is an advanced user and does not really see the needs of a normal user.
In the case of KWin we are in the lucky (or unlucky) situation that our target user group should not even know that an application called “KWin” exists. The only user visible place where the name “KWin” is written is the crash dialog – and I do hope that a normal user never sees that one 😉 Of course that means that we never get bug reports or feature suggestions from “normal” users. This means we have to look at each suggested feature and each extension with the thought about our primary user group. In our mission statement we clearly define that KWin should go out of the way and the user should not notice that there is a window manager. This is something to keep always in ones mind.
But nevertheless we have and want to have advanced features. In the mission statement it’s written down that KWin provides a steep learning curve for advanced features. Think for example about things like window specific rules which are not really easy to define whithout understanding of window management.
From time to time it happens that features for advanced users are in direct conflict with our goals and what our primary user group needs. An example for that is the menu to change the window’s opacity in the window decoration menu. To be honest: it’s a quite geeky feature and soooo 200* (look what we can do: translucent windows!). It’s almost an embarrassing feature as it changes the complete window to being translucent instead of adjusting just the background. Not only is this feature quite geeky, it also clutters an already cluttered menu even more.
Based on that the menu got removed after some discussion a few releases ago, but we acknowledged the need of the experienced users and added shortcuts and mouse action support to the window decoration for changing the opacity. So we removed one way at a user visible place and replaced it with several ways to alter the opacity.
Nevertheless over the time I have seen a few complaints about the removal of the feature and it made me think what we can do about it. Of course we don’t want to bring it back, but we also don’t want to anger our advanced users. Since 4.9 we have the wonderful possibility to have scripts and so I decided to extend the scripting support to allow adding entries to it from scripts.
This means since todays git master you can execute the following script to get your Window Opacity menu back:
registerUserActionsMenu(function (client) { var opacity = Math.round(client.opacity*100); return { text: "Window Opacity", items: [{ text: "100 %", checkable: true, checked: opacity == 100, triggered: function () { client.opacity = 1.0; } }, { text: "75 %", checkable: true, checked: opacity == 75, triggered: function () { client.opacity = 0.75; } }, { text: "50 %", checkable: true, checked: opacity == 50, triggered: function () { client.opacity = 0.5; } }, { text: "25 %", checkable: true, checked: opacity == 25, triggered: function () { client.opacity = 0.25; } }, { text: "10 %", checkable: true, checked: opacity == 10, triggered: function () { client.opacity = 0.1; } } ] }; })
I intend to make this script part of 4.10, but before I can do so we need i18n support inside the scripts or the titles of the menus cannot be translated.
One can also change transparency in other ways if needed. In the KDE preferences you can go to “window behavior” and “title bar” (I only translate from german, so it may be named slightly different). And then you can set “Mousewheel on title bar” to “change transparency”.
It works quite well at least since KDE 4.2 and is not cluttering the menu. I also think it is a very user friendly way to change it there.
After the opacity menu was removed, I enabled cycling through window opacity with [ALT]+[MOUSE WHEEL] on my installation.
And I have never missed the menu since, as the mouse wheel solution is much more convenient.
I also added a “stay on top” button directly to the title bar (to replace the imo useless “visible on all desktops” button), so now I don’t really need the window decoration menu at all anymore.
Maybe a generalized rule of thumb can be derived from that: Instead of accomodating power users by cramming every conveivable feature into the application’s menus/toolbars, provide ways to customize the application using the configuration backend.
PS: I like that elegant JavaScript API… I didn’t realize KWin scripting was so easy, I’ll have to keep that in mind if for the future I ever want to customize KWin in a way that is not exposed through the GUI interface…
I have to say, I did notice this feature going away (as I used it from time to time, normally to compare or copy information between windows on small displays) but never looked up the alternative shortcuts.
Thanks for taking care of us lazy users 🙂