Small discussion: How reasonable is icon on Cancel/No button? Uri's position that ideally no buttons should have icons.

A small step towards this is to consider removing icons from Cancel/No buttons and alikes. Extreme case that made me to ask about this:



Sometimes the Cancel button is the only icon supplied, and the confirmation button has no icon, would that suggest the confirmation isn't the primary element of the message? :



So also in this case, wouldn't removing the icon from Cancel button improve things?

Once any change is approved we'd mirror it at https://techbase.kde.org/Projects/Usabi ... G/Messages. And the implementation in KDE Frameworks would be really easy.

There's a setting for this which impacts SH_DialogButtonBox_ButtonsHaveIcons in every KStyle inheriting style and also the platform theme.

Personally, I don't like the icons on those buttons at all[1], so they should *all* not have them in *all* cases.

However, those icons _can_ be a help, if the pushbutton only comes in English, while you only speak Hindi, Mandarin or Russian etc. (It tells you "ok" or "cancel" - though you probably cannot read the dialog text either

My 2¢ would be to default "ShowIconsOnPushButtons" to false (currently defaults to true), but keep the option.
(Because of the platform theme, this will affect plain Qt apps which are not translated as well)

[1] At best, you're duplicating information, at worst cause contradiction/ambiguity and in any case clutter the GUI.

HIG 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.
* If icons are applied (or not), this style should be used consistently for a group of buttons.

Reason to write it in this way was consistency to the actual usage. But I'd agree on icon free confirmation buttons.

Same here: If we can make all icons on buttons go away at once, let's do it!

colomar wrote:Same here: If we can make all icons on buttons go away at once, let's do it!

That's probably as easy as changing the defaults

@luebking what about non-KStyle styles, basically QStyles shipped with Qt and third-party?
The former have SH_DialogButtonBox_ButtonsHaveIcons == false I guess?
Others can just follow recommendation, or?

Still, if someone likes the icons and re-enables them, my proposal is to de-clutter the messages, literally. How about this? Also easy to implement in KMessageBox.

https://git.reviewboard.kde.org/r/121019/
https://git.reviewboard.kde.org/r/121020/
https://git.reviewboard.kde.org/r/121021/

luebking wrote:https://git.reviewboard.kde.org/r/121019/
https://git.reviewboard.kde.org/r/121020/
https://git.reviewboard.kde.org/r/121021/

A new speed record!

I changed the guideline:

* Do not use icons for confirmation buttons like OK, Apply, or Cancel.
* Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.

Ummmm… moooooment.

So, because some icons don't work properly (which is clearly a mistake in the theme since I cannot recall such incidents from Oxygen) we sacrifice recognizability and turn off icons for all buttons?

Tick - Apply, Star - GHNS, it's all visible at a glance. But yeah, icons and colors are uncool, text is the future.

kbroulik wrote:Ummmm… moooooment.

So, because some icons don't work properly (which is clearly a mistake in the theme since I cannot recall such incidents from Oxygen) we sacrifice recognizability and turn off icons for all buttons?

Tick - Apply, Star - GHNS, it's all visible at a glance. But yeah, icons and colors are uncool, text is the future.

We still have icons on toolbar buttons by default I guess?

My 2c
(leaving asside the actual *bugs* about the icon not being the right one that matches the button 'action')

Personally, I do like icons on pushbuttons and the redundancy it brings. It teaches me what icon goes with what action, so that I can use 'icons only' toolbars without having to think too much.

Also, the default for toolbars is "text beside icons". Same redundancy as for toolbuttons, and more of a pain because there usually are many more toolbar buttons than push buttons.

Should this (the toolbar default) also be changed ? To text-only ? (no no) ? To icon only ? (I'd then argue that this would make it hard to identify an icon to an action, since there is nowhere overlap between the two)

Or what makes pushbuttons so different from toolbuttons that one is allowed to be redundant and not the other ?

Best,

Hugo

oh, and I forgot menu items

Heiko Tietze wrote:I changed the guideline:

* Do not use icons for confirmation buttons like OK, Apply, or Cancel.
* Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.

OK, more questions:
* Given the above changes, is this up to date regarding icons? https://techbase.kde.org/Projects/Usabi ... mmand_Link
* Would it be useful to add "does not apply to toolbar buttons" in these sentences?
* BTW toolbar buttons: can exceptions to their "text beside icons" default be codified? Maybe a term such as secondary toolbar? Open/Save dialogs use icon-only toolbar buttons for a reason (probably the space). And this is the case in numerous panes containing toolbar-like structures (like In Calligra https://www.calligra.org/?attachment_id=3119). I am using these buttons in Kexi too in "local", small context-dependent toolbars, it's hard to imagine them in text below icons mode, so there's no even option to show text. Text beside icons is used where possible, but soon there won't be space for that - http://kexi-project.org/pics/2.8/kexi-2 ... e-data.png).
* Similarly, how about explaining toolbox buttons and their icons somewhere? Krita has these buttons without text by default.

I am sorry if some of this is explained somewhere already.

+ how about explicitly mentioning special cases: Add/Remove icons that can be displayed as +/- icons? Practiced on Mac and newer MS apps (http://msdn.microsoft.com/en-us/library ... 65470.aspx).

hugo.pereira@free.fr wrote:Also, the default for toolbars is "text beside icons". Same redundancy as for toolbuttons, and more of a pain because there usually are many more toolbar buttons than push buttons.

Should this (the toolbar default) also be changed ? To text-only ? (no no) ? To icon only ? (I'd then argue that this would make it hard to identify an icon to an action, since there is nowhere overlap between the two)

I raised questions about toolbars in very the same time And mentioned secondary toolbars. They actually exist.. what default they have? I'd propose icon-only for them.


I think skipping text in toolbars is caused by the lack of space when there are usually many buttons (as you correctly mentioned too). Maybe it would be good to explain this concept in the HIG.