[kde-guidelines] Styleguide: Toolbar

[Heiko Tietze]

On Thursday 03 October 2013 17:43:56 Thomas Pfeiffer wrote:
> > * Avoid using menu-, split-, and toggle buttons in tool bars. They do not
> > fit well the concept of fast access.
> 
> We've discussed this before, and I disagree regarding split and toggle
> buttons.
> Yes, a menu button does not make sense for a toolbar, because it would be no
> faster than going to the main menu. A split button, however, doesn't sound
> that unreasonable to me. The button part allows for fast access, whereas
> the menu part allows - two-click - access to related buttons. Besides,
> where else would split buttons be used if not in toolbars? This could still
> be discussed, though.
> 
> What clearly does not belong in this list, though, are toggle buttons.
> Actually, the main HIG page says "Use a toogle button to indicate a state,
> preferably in toolbars only". Moreover, they do work perfectly well for fast
> access: A single click changes something, you cannot go faster than that ;)

I changed the point as you suggested
* Do not use menu buttons in tool bars. They do not fit well the concept of 
fast access.

But let's have a look onto kmail:

Send +, Queue + (Both menus expands all accounts)
Rich text (It toggles itself plus a toolbar with formatting stuff)
Spelling (Does not toggle but runs the action)
Attach + (File with dialog and, separated, vcard)
Cut, Copy, Paste
Sign, Encrypt (Probably a toggle button, I don't know)
Add smiley (Opens a floating panel to choose the object)

How do I figure out, if a button really only toggles something, which means I 
can undo my action, or if the button changes something completely? How do I 
know which options are available under the menu of a split button? And isn't 
the number of clicks identical if I invoke the action via main menu? 

The account can be controlled by the identity, and toggle buttons can be moved 
to menu because they are rather rarely used. The only menu which makes sense 
is the smiley stuff. And this is a menu button.

My intention is to define restrictions by the HIG which force devs to rethink a 
workflow. The more option we allow the less clear interfaces become.