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

Please notice that this does not affect pushbuttons in general, but those in the dialog buttonbox.

3¢
----
Those come in a specific[1] order (depending on a stylehint, as you will know and either use generic terms (Ok, Cancel, Apply, Help) which are so much omnipresent, that one might argue that the text is iconic by itself, or with a specific text, describing an action ("Submit bug") which you'll often have trouble to provide a speaking icon for.

Personally, I'd btw. be fine if I could have ONLY icons there, but this will lead to inconsistency at some point.

--

Toolbuttons are a different kind of beast.
There are indeed those typical and very generic "New, Open, Save, Print" ones, but actually i've removed those everywhere (in favor of common shortcuts), but the "typical" usecase for a toolbutton is the "regular task in this application", like eg. changing the rotation, the zoom, the tool or view mode in okular.
Eg. these buttons all have two-word labels and strings like "Slection Tool" occur nowhere else. Those strings are not iconic by themselves.

As for the default toolbutton mode:
I personally dislike the "text aside" default, because it's a horrible space waste (horizontal alignment of text and items)
For space reasons, I use icons only (you learn w/ the tooltip and if I don't know what an icon means after a short while, the action is not worth being in the toolbar) and would select "text below" otherwise.

--

On popup menus:
I don't use icons there. Menus are used occasionally only, the icons are tiny - and that means i've to read the text anyway. So the icons are completely redundant eye-catchers that divert me from the actual information.


[1] If you're not aware of the impact of the order, change it (eg. to Mac style) and see how often your mouse will go to the wrong side =)

jstaniek wrote:@luebking what about non-KStyle styles, basically QStyles shipped with Qt and third-party?
The former have SH_DialogButtonBox_ButtonsHaveIcons == false I guess?

Unless the style explicitly implements a return for SH_DialogButtonBox_ButtonsHaveIcons, QCommonStyle will invoke the platform plugin, ie. the KDE setting.
If a style statically returns true, you'll get icons (on many buttons) regardless of the setting - there's no way around that. (Otoh, a style can simply skip icon rendering on *all* pushbuttons that have non-empty text)

kbroulik wrote: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?

While Jarosław started this very topic on some particular icons, Uri and others (inc. me, I assume have positioned on their opinion on icons on Pushbuttons in general before.
I don't think that the fail of few icons (which would need to be improved for ppl. who'd re-activate pushbutton icons anyway) is any driving force here, but just a trigger to visit this decision.

jstaniek wrote:* Given the above changes, is this up to date regarding icons? https://techbase.kde.org/Projects/Usabi ... mmand_Link

Yes, but don't mix it up with normal links. It says, for instance, to have it like this
Print
but you are still allowed to use it as a 'go to', e.g. Last page.

jstaniek wrote:* Would it be useful to add "does not apply to toolbar buttons" in these sentences?

I don't understand what you mean. Why should it?

jstaniek wrote:* 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)...

I'm not a friend of if-then guidelines. If we introduce a concept like secondary toolbars it adds confusion. (I wouldn't call it a toolbar but rather a sidebar.)
Calligra clearly violates the HIG - with a more or less good reason. But some of the buttons are toggle buttons, that do not have a caption.
Personally, I switched off the text in toolbars to have more symmetry and less clutter. But KDE apps do use text because to support novices and a11y, so we wrote the HIG in this way.

jstaniek wrote:* Similarly, how about explaining toolbox buttons and their icons somewhere? Krita has these buttons without text by default.

Do you have the mentioned toggle button in mind?

luebking wrote:

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

Please notice that this does not affect pushbuttons in general, but those in the dialog buttonbox.

mmm here (kde4) unchecking 'show icons on button' (the settings whose default you change ?) does affect all pushbuttons not only the ones on dialog.
Or are we talking about a different thing ?

KPushButton indeed invoked the setting directly and now interprets "SH_DialogButtonBox_ButtonsHaveIcons" (DialogButtonBox_Buttons!) unconditionally.
KPushButton is however deprecated and the QPushButton behavior is tied to a "QDialogButtonBox" parent.

Heiko Tietze wrote:

jstaniek wrote:* Given the above changes, is this up to date regarding icons? https://techbase.kde.org/Projects/Usabi ... mmand_Link

Yes, but don't mix it up with normal links. It says, for instance, to have it like this
Print
but you are still allowed to use it as a 'go to', e.g. Last page.

OK

Heiko Tietze wrote:

jstaniek wrote:* Would it be useful to add "does not apply to toolbar buttons" in these sentences?

I don't understand what you mean. Why should it?

Well, second item of "Appearance" mentions exception for toolbars. Fourth stays now as "Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons." -- if applied to toolbar buttons we can encounter a series of label-like toolbar buttons if these lack icons. I do not even mention that the horizontal space would be quickly consumed. Example for Kate: http://wstaw.org/m/2014/11/10/plasma-desktopwv3979.png (please ignore usefulness of these actions brought to the toolbar, users are really various needs and taste, we have given them ability to freely edit toolbars).

One extra question I feel is "do we really want text aside of icons for the toolbars?"

Heiko Tietze wrote:

jstaniek wrote:* 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)...

I'm not a friend of if-then guidelines. If we introduce a concept like secondary toolbars it adds confusion. (I wouldn't call it a toolbar but rather a sidebar.)
Calligra clearly violates the HIG - with a more or less good reason. But some of the buttons are toggle buttons, that do not have a caption.
Personally, I switched off the text in toolbars to have more symmetry and less clutter. But KDE apps do use text because to support novices and a11y, so we wrote the HIG in this way.

Yeah, I am afraid the clutter by default would be what nontrivial app gives the users if it tries to comply with the HIG. I yet have to see more complex app that has no idea of secondary toolbars; even iWork, while it has first level of icon reduced to main "tabs" (exactly as in Ribbon, just they use popup menus instead of tabs), its secondary toolbar is naturally text-less (see the Numbers: http://images.amazon.com/images/G/01/so ... s-hero.jpg).
Regarding novices: with specialized apps, novices fill lost initially, our work is not to have them lost and give up.

Moveover, do we agree that the sidebar of complex apps such as Calligra, or a toolbox, say, of Krita/GIMP couldn't have text below/aside of icon that fits in? Even now many actions are hidden in modal dialogs, as the apps get even more features, text cannot fix comfortably. It's even worse after translation. I know you're busy but maybe later more complex apps would benefit from your help, when their needs can be addressed carefully. It would be cool.
I am not sure "Simple by default" is the answer in this case. Word processor or even Integrated Development Environment for example is a damn complex creation that offers many features that are used: most of the users touch 20% of features but usually different 20% of them. I imagine that the feature set (except really supplementary or 3rdparty) cannot be reasonably hidden in plugins, options, not enabled by default, etc. so the normal user start with no specific functionality and configure to their needs.

BTW, how is a11y related to visible text? I though extra helpers such as text line commands, shortcuts (also http://stealthsettings.com/wp-content/i ... office.jpg), can be provided for these uses.

Heiko Tietze wrote:

jstaniek wrote:* Similarly, how about explaining toolbox buttons and their icons somewhere? Krita has these buttons without text by default.

Do you have the mentioned toggle button in mind?

I've moved this topic to viewtopic.php?f=285&t=123637 because it's quite big in itself.

Button
Icons on buttons: I added the exception about icons at toolbar buttons to the button HIG.

Toolbar
Second toolbar: Do we have any KDE software with more than one toolbar?

Toolbar buttons
Text position: Yes, text on the right side occupies some space. But with text below I don't feel home with Calligra. I don't think it should become a possible default.
a11y: I guess screen readers access the tooltip but I'm not sure.
Icon/Text on/off: Seems to me that we all don't want text on buttons.

jstaniek wrote:Moveover, do we agree that the sidebar of complex apps such as Calligra, or a toolbox, say, of Krita/GIMP couldn't have text below/aside of icon that fits in? Even now many actions are hidden in modal dialogs, as the apps get even more features, text cannot fix comfortably. It's even worse after translation. I know you're busy but maybe later more complex apps would benefit from your help, when their needs can be addressed carefully. It would be cool.
I am not sure "Simple by default" is the answer in this case. Word processor or even Integrated Development Environment for example is a damn complex creation that offers many features that are used: most of the users touch 20% of features but usually different 20% of them. I imagine that the feature set (except really supplementary or 3rdparty) cannot be reasonably hidden in plugins, options, not enabled by default, etc. so the normal user start with no specific functionality and configure to their needs.

I still think that "Simple by default, powerful when needed" can be done with inherently complex applications, if we make configuration easy for users (e.g. by using "Australis style" configuration) so that users can put the functions they need regularly in the toolbar, those that they need sometimes in a menu and those they never need out of sight.