KToolbarButton popup delay (Re: Bug report and feature request)

Gunnar Schmi Dt gunnar at schmi-dt.de
Mon May 12 16:20:40 BST 2003

Hash: SHA1


On Monday 12 May 2003 01:03, David Faure wrote:
> On Monday 12 May 2003 00:07, Gunnar Schmi Dt wrote:
> > Hello,
> > [...]
> > If you do a long click
> > onto the toolbar icon the popup menu shows up. If you then keep the mouse
> > button pressed while you move the mouse onto an entry in the sub menu and
> > then release the mouse key, the tool bar icon will _not_ return to its
> > initial state (e.g., it either does not show a border when the mouse
> > enteres the icon or it does always show this border).
> Hmm, I can't reproduce this, and AFAICS I fixed that bug 13 months ago
> according to
> http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdeui/ktoolbarbutton.cpp?s
>ortby=date#dirlist (see revision 1.65), before KDE-3.0.
The tool bar icon gets deselected. However, it does _not_ become selected 
again if you move the mouse over it (as it normally does). If the menu is 
delayed the selection state becomes toggled or deselected everytime you 
activate the main action by short clicking on the tool bar icon.

In this sense it is either an other bug or the bug was only half fixed.

> I guess it's another bug...
> Does it really happen with the bookmark toolbar in Konqueror? Those popups
> aren't delayed... Where do I find delayed popups with submenus?
The effect is in every popup menu in a tool bar (regardless whether the icon 
is delayed or not). You can find a delayed pop up menu with submenus in the 
phrase book edit window of KMouth.

> > With KDE 3.1 you can also get
> > this effect by clicking exactly 500ms on an icon with a delayed popup
> > menu.
> How do I click _exactly_ 500ms? I can count fast, but not that fast :)
> [...]
In the meantime I did some additional testing. In KDE 3.1 the effect does show 
up if you click long enough for the pop up to show but short enough to have 
the mouse key released before the popup is on the screen. This can either 
happen with some trying on delayed popup menus or with very short mouse 
clicks on non-delayed popup menus.

So to speak it seems to be a race condition which is additionally guaranteed 
to go wrong when doing a one-click selection in submenus.

I do not know whether this effect is still in HEAD --- the popup is drawn too 
quickly for my tests ;-)

Gunnar Schmi Dt
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list