One of the new features in KWin 5 is a completely rewritten configuration module for our Desktop Effects. In KWin 4 our module was based on KPluginSelector, which is a great widget for a small list of plugins, but it was never a really good solution for the needs of KWin.
Also we noticed that a QWidget based user interface is not flexible enough for what we would like to provide (e.g. preview videos). So when QtQuick came around we had the first experiments with reimplementing the selector with QtQuick, but with the lack of what today is QtQuick Controls it never left the prototype state. But it encouraged us to use one GSoC project on redesigning the control module from scratch and Antonis did a great job there to lay the foundation for what we have now in the upcoming alpha release.
The most noticeable change is that the new control module just focuses on the Desktop Effects. What we learned from our users is that they are only interested in configuring the effects and that the other options exposed in that control module bare the risk of users changing and breaking their system. Thus we decided to give the users what they need and move all other options into another control module.
In order to give the users the possibility to focus on the effects we also did some cleanup in the list and all effects which are not supported by the currently used compositing backend are hidden by default (e.g. OpenGL effects when using XRender). Also all internal or helper effects are hidden by default. These are effects which replace functionality from KWin Core or provide interaction with other elements of the desktop shell. Normally there is no reason for users to change that except if they want to break their system. That’s of course a valid use case and so there is a configuration button to modify the filtering of the list to show also those effects.
Last but not least our effects got extended by information on whether they are mutual exclusive to other effects. For example one would only want to activate the minimize or the magic lamp effect. Both at the same time result in broken animations. For effects in a mutual exclusive group the UI uses radio buttons and manages that only one of the effects can be activated. That’s the change I’m most happy about.
Check out the video to see the new configuration module in action and also see some of the new features I haven’t talked about. Please don’t tell me in the comments about padding issues and rendering problems. We can see those, too, and are quite aware of them. If you want to help iron out issues with Oxygen and QtQuick Controls check have a look to our wiki page.
if they want to break their system. That’s of course a valid use case
LOL
I didn’t see a grouping indicator with the radio buttons, is that deliberate?
When you have 2 groups of radio buttons (and no visual group indicator), they can’t be placed next/below each other.
falls under “not yet implemented” 😉
Maybe that grouping indicator could have its own checkbox so that radio buttons can stay true to its roots and not be checkable?
I agree, pressing an already-pressed radio button to disable it is very counter-intuitive…
Nice features, really like those, but agree on that. One solution could be a grouping headline for radio button items and a checkbox next to it. Once you uncheck it the selected radio button would stay on if there is any but the grouped items would get grayed out. They could not be selected until checkbox is once again checked.
+1
Something like “Animate minimization” and then, below it, the available minimization effects.
Or just another radio with the option “disabled” in the group.
Well, the video link is not working at the moment, but all the changes you mentioned sound great! I think I can speak for most everyone when I say that we really appreciate all that the kde developers have been doing in the past few years. I am excited to see this release, and the subsequent improvements that you and your peers have been documenting.
Thanks again.
The video feature is nice but looks kind of out of place .. maybe it would be better to show it as a popup?
I don’t think having a popup would be as good, but I would think keeping the buttons in the same place and just having the video appear below would look more natural.
I agree, it looks out of place. A popup would be nicer.
Thanks to all KDE devs for your work.
A little point: usually, a group of radio buttons hava a title, and a clear separation from other choices.
In the video, I see three radio buttons (Looking Glass, Magnifyer, and Zoom), but there is no clue that they are related apart from the fact they are radio buttons. IMO, it would be better to have a meaningful title (maybe “Magnifying method”, or something like that), and a clearly visual grouping design.
Looks great, but wouldn’t it be better to have a single group of the radio-button-enabled mutually exclusive effects to be visially separated from the other ones in some way? At least by adding a separator both above and below such a group? Otherwise it’s a little bit confusing.
On disabling showing the effects that are not supported by the backend, I feel that would cause quite a bit of confusion akin to “where did that effect go, I swear it was there somewhere last time I checked”. Also, people who set XRender first and then look at the list might think that KWin doesn’t support any more effects, while it actually does. Maybe it would be better if they were displayed, but greyed out and a message saying that the backend $backend_name does not support the effect be put somewhere?
That seems like it might take a lot of place in the list. Having unsupported features is bad enough, I think if they crowd the list of what available effects we have, it might just make it more painful to navigate.
Though I would indeed like to know which effects are not working. I could see however a single entry enumerating them at the end of the list, and matching the filter’s searches (so that we know that we didn’t misstype the effect’s name).
My idea is to put them all at the bottom, yes. It theoretically takes up space, but a user just needs a single glance to see that everything below a certain point is greyed out. The list also doesn’t take any more space than it does when you use OpenGL backends.
No, that would not be a great idea, because we go from “my effects are gone and I don’t know why” to “where are my effects, I swear I saw them there before!”
From a design point of view, the option of the backend should not change the order or visibility of items in the list. Disabling (greying them out) would be the most user friendly.
The problem I see is not how much space these disabled (greyed out) options would see on the list, but seeing them when he doesn’t search them. That would require to review the sorting and categories on the list, which is not a priority.
Adding an option to show unavailable option would not be a great solution as the checkbox would bloat the rest of the interface when for each use when this option would rarely be used.
Sure, it’s not the best way to handle it, but as long as effects don’t seemingly randomly disappear it sounds fine to me.
People don’t do that.
But it is a valid use case. Maybe not a lot of people do that, but I can see a scenario where one reads Phoronix, sees that XRender brings performance improvements, switches to KDE, then sets XRender first. Plus the issue arises in other cases as well (for instance, setting XRender for debugging purposes or having it preset due to driver issues on initial boot).
yeah exactly these kind of scenarios we want to prevent. It’s for users who understand what they are doing. If they believe in a Phoronix benchmark, they don’t know what they are doing by definition 😉
Will the successor of KPluginSelector support keyboard navigation? Try to navigate with only Tab and arrow keys on KDE 4, it’s impossible.
This post made me visit the desktop effect module, and out of pure nostalgia I enabled Wobbly Windows 😀
I’ll probably disable it again soon…
Considering the radiobuttons – it would be good if you could take a look at (and possibly follow) the styleguide (or help to improve it, if it does not fit your needs):
http://techbase.kde.org/Projects/Usability/HIG/Radio_Buttons
Thanks a lot for this, especially for the radio buttons – each time I opened the effects window, I wondered which of these effects actually make sense to enable in parallel 😉
Great work 🙂
Great .. finally I’ll know what the effects do :). I often was wondering “and what is this effect doing anyway?”.
Zum dritten Mal:
Deine Links in deinen Benachrichtigungs Email führen zu deiner Administrations Seite und sind somit für uns alle nicht zielführend, ist das so schwer umzustellen ?
Ja ist es. Ich hoffe ich habe email nun komplett deaktiviert.
This sounds wonderful! However, I’d like to make two remarks.
The first is that clicking again on a selected radio button to disable it is very unintuitive. There should be a dedicated “None” radio button for that purpose.
The second is that breaking the desktop is actually not a valid use case, and it shouldn’t be reflected in the UI at all. Editing kwinrc manually is perfectly reasonable for this kind of thing.