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

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 May 2003 00:07, Gunnar Schmi Dt wrote:
> Hello,
> 
> On Sunday 11 May 2003 22:55, David Faure wrote:
> > [...]
> > On Sunday 11 May 2003 19:32, Gunnar Schmi Dt wrote:
> > > I want to suggest that the time before the delayed tool bar pops up
> > > becomes configurable. Currently it is fixed to 500ms. The reason why I
> > > want it to be configurable is simple: Persons who are slow with their
> > > fingers.
> >
> > To answer your question about whether it's in kdelibs or Qt: it's in
> > kdelibs. // Delay in ms before delayed popup pops up
> > #define POPUP_DELAY 500
> > at the top of ktoolbarbutton.cpp
> >
> The place of the fixed time was clear to me. What I do not know, though, is
> the part where the bug is in. (If you tell me whether the bug is in kdelibs
> or in qt I will file a normal bug report.)

kdelibs, surely.

> 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?sortby=date#dirlist
(see revision 1.65), before KDE-3.0.

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?

> 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 :)

> > Now, what I'd like to ask is:
> > Qt has a configurable delay for "drag time" - it's the minimum time you
> > need to click somewhere before it starts a drag. Isn't this quite similar?
> > Would it be ok if we used the configurable dragtime in KToolbarButton,
> > instead of adding yet another configuration option?
> 
> Off course we can use the drag time. It is only important that it is possible
> to configure the time. If there is already a similar configuration option,
> then it absolutely makes sense to re-use this option.

A rather easy fix then ;)

- --- ktoolbarbutton.cpp  15 Jan 2003 23:40:28 -0000      1.69
+++ ktoolbarbutton.cpp  11 May 2003 23:03:28 -0000
@@ -50,9 +50,6 @@

 template class QIntDict<KToolBarButton>;

- -// Delay in ms before delayed popup pops up
- -#define POPUP_DELAY 500
- -
 class KToolBarButtonPrivate
 {
 public:
@@ -705,7 +702,7 @@ void KToolBarButton::slotPressed()
     if (d->m_isPopup)
     {
       d->m_delayTimer->stop(); // just in case?
- -      d->m_delayTimer->start(POPUP_DELAY, true);
+      d->m_delayTimer->start( QApplication::startDragTime() , true);
       return;
     }
     else

- -- 
David FAURE, faure at kde.org, sponsored by TrollTech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Wireless network using 2 laptops; tomsrtbt linux - http://blackie.dk/~dfaure/wifi.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+vtbZ72KcVAmwbhARAt54AKCtKCb/QlGi5zNcNlMnxXzoJJjCewCglR8u
S3oXbsRCGK61zgZoM4sAf0U=
=bhD/
-----END PGP SIGNATURE-----