[window deco kcm] taking too much screen real estate (hardly useable on a netbook)

[star-buck]

Suggestion: move the rarely (if ever used twice) window decoration buttons arranger in a popup again.

[mgraesslin]

That's something I would like the VDG to decide on. I was not happy with the dialog, that's why I removed it. There are certainly other ways to do it which compromise between screen estate and not needing a popup

[star-buck]

Just me being curious: What was it you felt wrong about the dialog approach?

[mgraesslin]

Well for that we first have to ask what was the reason to move it to a dialog: and one of the main reasons was that it was extremely ugly with extremely old window decoration buttons. So it was certainly a part of hiding it.

What I didn't like about the layout with the dialogs was:

• the two rows of buttons
• that the feature is hidden
• not having all of the "global" decoration settings on one page

With the new layout we addressed some of these problems, the row of buttons got removed, the GHNS is merged into the search bar, the decoration specific button is merged into the decoration and the global settings are available. Reintroducing a button for opening a dialog would partly destroy these improvements again.

[star-buck]

Some valid reasons. Making the improved button re-arrangement area a dialog would still make the window deco kcm better IMO, because:

• the feature is presumingly only used once (if at all) and seldomly after having arranged the buttons to ones liking
• the feature is probably used a lot less than the "Get more window decorations", which is also a popup for other valid reasons
• making a button clearly labelled as "Button Reorder" doesnt make it "hidden"

Just an idea: What I always missed in the window deco KCM is a method to directly remove installed themes (like for wallpapers?), which is really a hidden feature now :)

[mgraesslin]

well it has advantages and disadvantages. My fear is that the feature is too hidden if moved to a dialog. Users might and will not expect that the button layout can be configured as none of our competitors (e.g. OSX, MS Windows, Ubuntu, GNOME) offer such a functionality. I think that there are solutions which fix the given issue and at the same time don't move the config into a dialog.

What I always missed in the window deco KCM is a method to directly remove installed themes (like for wallpapers?), which is really a hidden feature now :)

That should be relatively easy to do now, yes.

[mgraesslin]

I just created a solution (https://git.reviewboard.kde.org/r/122985/ - has screenshots) to show an additional configuration button on a small window, but show the button configuration interface on a large enough window.

[star-buck]

Hi Martin,

I wanted to give you some feedback on your proposal, so please don't see this as starting an argument for arguments sake, nor convincing you or anyone else of anything, just some food for thought trying to look at the current state from a users point of view , while reading the debate and staying neutral there: https://git.reviewboard.kde.org/r/122985/

Your main fear was that the option might be "too hidden" if not presented the way it is now. Now from the screenshot with the "button state", could one think that the feature is "hidden"? To me personally, the button looks clear and prominent as an option, so that clicking on that button, something will happen (as a new user, I would expect a popup) that allows me to (easily) change window decorations button order and selection, just as the button label clearly states. Assuming that this button is too "hidden" would imply that any button, any tab or just anything that is clearly visible and readable on screen is "too hidden" just the same, which imho is not the case here, as the button is always and continously visible right from accessing the kcm, so no need to scroll down or look out for that option as if it would be partly hidden.

The other question to look at is how to present the button configuration dialog: From my understanding, the more often something is used and the more critical an option is to the user, one could assume the more prominently displayed the option should be for the user to notice in case he/she is looking for it, so it doesnt get "overlooked".

One would assume any newly installed distro with plasma instance has setup window decotration to be in a working state, either with some additional buttons or buttons on either side of the window. So there might be the wish to reduce some buttons, add some or change position, or to change the default theme overall, but neither seems critical (compared to changing for example a wrongly configured keyboard layout, which option is currently really hidden and cumbersome to invoke and therefore imo frustrating for anyone needing this to change and spot it right away).

So if not for the urgency, how about the frequency of button reordering vs. theme changing offered by that kcm? Again, I would assume, that if a user was dissatisfied with the initial button setup of his plasma installation, he/she will have the wish of how his buttons should be like, so he/she will change decoration buttons to his or her liking. After that, I would argue there is a very low incentive to change buttons ever again, especially not on a regular or frequent basis compared to for example downloading and trying new themes. Therefore the importance after first use for window decoration button order is reduced to almost become negible. At that point though the ever-presence of the full dialog starts to contrast with the reduced-to-zero importance. It is somewhat like an ever present "Tips of the day" window or (of course not as annyoing) as an ad inside an android app taking away screen space. Now it could still be there and simply ignored (though it always does look a bit confusing because of its similarity to be confused with an actual theme), just taking away space and doing not much else after its first usecase. But then, things still need attention exactly because of how it is done now, with the exact usecase you're trying to solve, where the presence of that dialog becomes so overwelming in a reduced vertical screen realestate case, that something needs to be done about it, hence your proposal.

So because of the way it is implemented it gets more complicated and further inconsistent by keeping up that solution and deciding how much is visible, then turn it into a button without an option to close the dialog again, etc. while on the other side making it a modal window again (that is far improved and gretaly done compared to the old one) would not even need to write more code to handle it.

To conclude, I personally would say both scenarios (the one with more and the one with less vertical screen real estate) would benefit from having the option presented the same way as in your view-small screenhot, but invoking a modal window that can be closed afterwards.

Again, just my 2 cents, so I am posting this here as to not interrupt the discussion on reviewboard, where the real discussion takes.

On a smaller note: Is placing all of the 3 options underneath in that "too less vertical space" screenshot HIG related (instead of maybe two options in one row to not waste additional vertical space)?

[mgraesslin]

Thanks for your feedback. It helps me understanding your reasoning.

I think we have different assumptions from our user base and what they expect. You assume that we have the "visual tweaker" who changes the look and feel every few weeks, while I assume that this not so often used as one might think (based on reading thousands of kwin support information output in bug reports and the low download numbers on kde-look (most downloaded is < 7000 downloads)).

Given that I just put the need of the configuration options higher.

Btw. changing to modal dialog is also not a trivial change to the code base and causes inconsistency in the behavior (been there ;-) ).

[mgraesslin]

should be fixed in 5.5 - Thomas reworked it to use tabs.

[star-buck]

closing