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.
