Heiko Tietze wrote:And to quote Thomas: "Who needs to minimize an app when the workflow has reached a critical state, which is the only situation to show modal dialogs?"

You mean me? In which context did I say that?

lazyit wrote:This discussion makes me think , if there is a need for another topic more generally, on the user experience, I do not know if this is the task of the VDG , but I think so!What I mean is , we really want the user experience of KDE -Next is by default the same as it is now on kde 4 ?I try to explain better , we still want that default KDE is always present in the classic way with the plasmoid Folder View in the upper left ?We still want that by default is set to the single-click on the folders ?As in this case , we still want the buttons of the windows set in a certain way ?And anyway, do you really believe that in the current default settings , there is nothing to refine or improve ?To me it would take a study on this , with no obligation to change, but simply to improve if it is possible , the current experience , especially if you think that there are unnecessary things or improvement, or if you know that there are things , for example, all change after the first start

The approach to Plasma Next is "Evolution instead of Revolution", which means that the first release will behave very similarly to the current Plasma, and then with each release, improvements will be introduced. This way we won't scare existing users away and developers can concentrate on implementing a few changes at a time and doing them right.

colomar wrote:You mean me? In which context did I say that?

Not in a particular posting. Like Jens is being quoted on high level, you said something like 'keep track on the workflow' somewhere else. It was just a rhetorical joke.

A few notes: the buttons are added when the window indicates that they are needed. If a window says it's closeable, it gets a close button. Thus removing the button would be wrong (and not possible as KWin wouldn't know). Other actions like Alt+F4 or Alt+F3->close, menu button -> close would all still supported and would result in an inconsistent UI.

The help button gets added when the window indicates that it provides quick help. If that's no longer needed, remove it from the config modules, but don't touch the button. It needs to support more than just KF5 applications.

The maximize and minimize buttons are no brainers: those won't be removed, that goes against the design of KWin to not restrict features. Maximize and minimize could only be removed by completely removing that feature and there is no reason to do that. Which is also reason enough to not remove the close button as that would result in an inconsistent UI with some times the maximize and some times the close button being the right most.

mgraesslin wrote:The help button gets added when the window indicates that it provides quick help. If that's no longer needed, remove it from the config modules, but don't touch the button. It needs to support more than just KF5 applications.

Yep, that's exactly what I meant: We should not just remove the button, but tell developers of KCMs and other applications via guideline that they should not use quick help.

All sounds perfectly reasonable to me mgraesslin. I don't think any of this needs to be compelled on a technical implementation level. I think updating guidelines like colomar suggests can get us a long way there. We can satisfy any part of an overall design vision by communicating with application developers on how to best use the features provided by the technical implementation. So, in this case, for example:
"If you don't mean for a dialog to be resizable, remember to set the appropriate dialog window settings"
or
"If your application no longer provides context help, remember to disable it in your application window settings"

My own sentiment is that we walk down the path of providing guidance to developers to improve visual design, rather than looking for yet another technical solution and pretending that is what's really preventing beautifully crafted applications and environment. Kwin (and KDE frameworks and Qt, etc.) is amazingly powerful. I think we should focus on learning together how to use that power to create even greater beauty and elegance.

Alake for president!

alake wrote:My own sentiment is that we walk down the path of providing guidance to developers to improve visual design, rather than looking for yet another technical solution and pretending that is what's really preventing beautifully crafted applications and environment. Kwin (and KDE frameworks and Qt, etc.) is amazingly powerful. I think we should focus on learning together how to use that power to create even greater beauty and elegance.

Very nicely put! And of course I would "veto" any "strange" approach like just hiding the maximize button.

I think that this is a problem with the current plasma-next beta. The blur dialog in particular is absolutly clutered with buttons (http://imgur.com/bdo90Ti). I think that at most the dialog should have a cancel, ok, and restore defaults buttons. The others are just duplicates. Would it be possible to have a survey run on this like the search settings, system settings, and plasma-next dialogs? At the very least the dialogs could be uncluttered if the icons were removed from the buttons.

enoop wrote:I think that this is a problem with the current plasma-next beta. The blur dialog in particular is absolutly clutered with buttons (http://imgur.com/bdo90Ti). I think that at most the dialog should have a cancel, ok, and restore defaults buttons. The others are just duplicates. Would it be possible to have a survey run on this like the search settings, system settings, and plasma-next dialogs? At the very least the dialogs could be uncluttered if the icons were removed from the buttons.

The HIG on buttons says: "Prefer using icons on buttons only for OK, Apply or Cancel like actions. Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons." Icons must not be cleared from all buttons until the community agrees in a completely new appearance (nobody has complaint about the 90th button style so far).

But you are right, the dialog is quite overloaded. Since no other secondary dialog out of the desktop effects offers the option to restore the default value (Restore Defaults) or to undo changes (Restore), I'd recommend to remove these functions and buttons. On the other hand, if the dialog contains more options, and thus is larger, the two buttons are left aligned and better separated. Maybe it helps to use short labels, i.e. 'Default(s)'. Another observation is that the alignment of at least the checkbox has to get fixed.

Putting all together is there really need to ask users about their opinions?

Heiko Tietze wrote:But you are right, the dialog is quite overloaded. Since no other secondary dialog out of the desktop effects offers the option to restore the default value (Restore Defaults) or to undo changes (Restore), I'd recommend to remove these functions and buttons.

Nope, that's a change in KWin/5. All effect configuration modules have now the reset and defaults buttons to follow the general layout of the KCMs. I considered it as a bug, that those KCMs did not have the buttons.

The usefulness of the "reset" button should be discussed in general. Its only purpose is to undo if you've messed something up, but that can be accomplished by clicking "cancel" and then reopening the KCM as well. I don't think this happens often enough to warrant a separate button. I for one have never ever used that button.

Hm, that's not what "Defaults" does, it shoud load the default ("factory") settings. That's useul, isn't it?

In my opinion, from my own usage, I think that there are only three useful buttons in a dialog like this. Those three buttons are: cancel, ok, and the restore defaults. The cancel button has represented the reset button for me in every other type of dialog outside of KDE, and I think that users know that if they want to reset they can just cancel the dialog and open it again. The ok button serves the usefulness of the apply button in a dialog like this one. I'm not saying that the apply button should be removed altogether from KDE applications (like gnome has done), simply that in a dialog, people make smaller changes, and they expect that closing the window through the ok button should apply these changes, at least in my experience. The restore defaults button is one that I always wanted in these dialogs, as I think that the single restore defaults button that appears in system settings per KCM has always been confusing, does it reset only the things on that page, or all the setting changed in that module. Having one in dialogs makes sense and offers value.

enoop wrote:The ok button serves the usefulness of the apply button in a dialog like this one.

We had the discussion about Apply somewhere else (or at the beginning of this thread): You do not need to close the dialog (via Ok) to make sure that your modifications are as expected with this feature. It is actually some kind of opposite function to 'Restore Default'.
As always: the more functionality you add the more you clutter a view. If we want KDE plain, googlish and easy to use then the Ok button would be all what a dialog needs. If many users want to 'Restore Default' values it makes sense to add this function (I'm not so sure about this notion). A compromise could be achieved by moving all non-disruptive functions (that is when the dialog is not closed) somewhere else in the dialog. Perhaps per unobtrusive context menu accompanied by an info button?