[kde-guidelines] Styleguide: Toolbar

[Thomas Pfeiffer]

On Friday 04 October 2013 16:46:50 Heiko Tietze wrote:
> 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. 

You have a point. How about "Do not use menu buttons in tool bars. They do not  
fit well the concept of fast access. Try to avoid using split or toggle buttons 
in order to keep the interaction with all buttons in the toolbar consistent".
That way we discourage but do not forbid toggle and split buttons.