Improvement of tool button in KDE4

Louai Al-Khanji louai.khanji at gmail.com
Mon May 25 20:58:49 BST 2009


On Thu, May 21, 2009 at 12:01 AM, Thomas Lübking <thomas.luebking at web.de> wrote:
> Am Wednesday 20 May 2009 schrieb Christoph Feck:
>
>> * 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.
> lame, bespin has 150 ;-P
>
>> * 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
>
> this is in particular why i'd vote against making "delayed" vs. "click and
> drag" either some HIG enforcement or style dependent.
> it's entirely about the user in person, his/her motorics and input devices.
>
> so such behaviour should be
> 1. configurable (regardless all "not too many options, please" yells -
> there's no "right" choice)
> 2. not handled by the style (as otherwise all styles would have implement
> some config for it or rule out some users or live with the "but style xxx
> does yyy" bug reports) - iff at all then by kstyle, but even that's no good
> solution as it would exclude the built in Qt styles
>
> (by taking a long dragDistance() into account the whole advance of this
> would be lost, so pen or even touchpad users would likely prefer the delayed
> variant in the first place)
>
> Thomas

Maybe I'm pointing out the obvious, but also note that you can call
QToolButton::setPopupMode(QToolButton::InstantPopup) if you want to
show the menu immediately.

-- 
- Louai Al-Khanji




More information about the kde-core-devel mailing list