Improvement of tool button in KDE4

Christoph Feck christoph at maxiom.de
Wed May 20 21:37:44 BST 2009


Hi,

some comments regarding the "menu toolbuttons".

* In Qt 4, there are three types of menu toolbuttons: separate menu part, 
immediate menu, and delayed menu. I think the "immediate menu" is only used 
when the user must select a menu entry to trigger the action. As for 
using "separate menu part" vs. "delayed menu" that seems to be a programmers 
choice. We really should ask HIG gals and guys if there are guidelines.

* The regions for the "menu part" and the "button part" are style depended. 
The PNG shows Skulpture style, which follows Plastique. I think the regions 
are different with Oxygen, it's long ago that I used it :)

* The toolbutton menu delay is read via QStyle::SH_ToolButton_PopupDelay, so 
wether it is configurable or not depends on the used style (the idea is that 
the delay should follow platform guidelines). Of course we could change that 
value for KStyle, because 600 ms is really too long (IMHO). I use 250 ms in 
Skulpture.

* If you are implementing "click and drag" with the delayed button, *please* 
think about users with a pen and respect QApplication::dragDistance(), as on 
a tablet it is (nearly) impossible to click without dragging. There are too 
many Qt4/KDE4 bugs with this issue already, probably the main reason why I am 
still using KDE3.

* Speaking of KDE3, Konqueror/3 uses the "delayed menu" instead of 
the "separate menu part" in Konqueror/4 for the "Go Back/Go Forward" actions, 
and Qt3 supports the "click and drag" for those buttons (with a good drag 
distance or delay).

* There is a discussion about the "Open" vs. "Open Recent" action on 
https://bugs.kde.org/show_bug.cgi?id=185312 I think Ark used a combination of 
those actions on a single tool button using the menu feature on the tool 
button. I am not sure if KDE has support for the "two action nature" of those 
menu buttons, as it would require two distinct actions in the menus. Maybe 
there needs to be some magic in KAction to support those things (one 
toolbutton but two menu entries).

Christoph Feck (kdepepo)

Am Wednesday 20 May 2009 17:47:32 schrieb David Faure:
> On Wednesday 11 February 2009, Miroslav Bendik wrote:
> > Hello,
> >
> > I'm sending my improved version of QToolButton with menu. In case of
> > standard QToolButton, it is necessary to hold a left clik for 600ms until
> > the menu will show up. In my implementation, it is possible to show the
> > menu immediately by simple click&drag. After the action, the menu will
> > appear immediately. Menu actions are launched by left mouse button
> > release over the menu item. It is also possible to launch standard action
> > like folder up in case of up button in konqueror.
> >
> > I'm aware that my implementation is not very user firendly. But on the
> > other hand, it has some advantages (
> > http://mireq.linuxos.sk/kde4/toolbar_buttons.png ) too. I would be really
> > happy if it was implemented. As we can find 2 types of such buttons in
> > KDE4. In my opinion, KDE4 should have one global settings for all buttons
> > in applications (SystemSettings / Apperance / Style / Fine Tunning /
> > Toolbar button type (buttons with special arrow / small buttons)).
> >
> > The source code of my implementation can be found at
> > http://mireq.linuxos.sk/kde4/toolBarMenu.tar.gz
>
> This looks interesting. I wonder if the usability team has any input on
> this (cf the PNG above, it explains the issue).
>
> I wonder about "yet another setting"... and whether the actual appearance
> shouldn't be done by the widget style instead, but this is all a bit
> outside my area of expertise. Any input from the widget style guys?




More information about the kde-core-devel mailing list