Bug 179267

Do you want this option for all the menus in all the KDE apps or for the classic KMenu application launcher only ? Thanks :)

Depends. It would be nice to have a configuration for all submenus kde-4-wide. But if it's easier to implement this only for classic kmenu, that would be ok for me, too.

I think this is only possible with QT-Styles. So this belongs to kdelibs, because it make no sense to define an own kstyle for the menuview, because the style should look like the global kde-style.

One possiblity would be to add to the method styleHint() in KDE/kdelibs/kdeui/kernel/kstyle.cpp

case SH_Menu_SubMenuPopupDelay: 
    return d->m_componentData.config()->group("KDE").readEntry("SubmenuDelay", KDE_DEFAULT_SUBMENU_DELAY );

and define a reasonable default KDE_DEFAULT_SUBMENU_DELAY-constant.


The problem with this solution is, that it would only apply to style derived from kstyle. It would be nice, to have this for all available styles. QTs defaults seem to be really slow for QT-4. For example the plastik-style-delay is much higher in qt4 as in qt3.

I have written my "own" style (a simple extension to plastique), to achieve my goal. Simply overridden the stylehint-method. Style attached. Would still be nice, if that was configurable for all styles. perhaps this should be reported for QT because it is difficult to solve commonly with current qt-api-design.

Created attachment 32740 [details]
Plastique extension for less menu-delay

have included binary to put in kde4-styles-dir

*** Bug 140114 has been marked as a duplicate of this bug. ***

*** Bug 167488 has been marked as a duplicate of this bug. ***

I reported a bug to QT:

http://bugreports.qt.nokia.com/browse/QTBUG-6517

I think there are 3 possible solutions:

a) make default popupdelay smaller like in qt3 (I think it is about 250 ms now, and was about 50 ms in qt3)

b) make delay global configurable in qt-config files

c) find a solution in kde by inheriting all qt-widget-styles and make delay-setting a general kstyle-option, which is configurable in kde4-systemsettings

SVN commit 1103180 by cfeck:

Move behavior related style hints from Oxygen to KStyle

This way all KStyles can respect them. The idea is to make the
submenu delay configurable in the future, and this makes sense to
do in a central place.

CCBUG: 179267


 M  +0 -8      kdebase/workspace/kstyles/oxygen/oxygen.cpp  
 M  +6 -0      kdelibs/kdeui/kernel/kstyle.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1103180

thanks. thats a right step. would it make sense to inherit all qt-styles to respect those settings, too, then? will I be able to set those settings in a config file, before a gui is ready?

Hope the submenu delay will be configurable soon. 

By the way, I feel it necessary to copy the following workaround from Bug 167488.

  -------  Comment #8 From  Christoph Feck   2009-05-26 21:58:32   (-) [reply] -------

Skulpture style fixes that bug:
http://kdepepo.wordpress.com/2009/01/05/skulpture-022-released/

Created attachment 43886 [details]
testing SubMenuPopupDelay

Hi, thanks for the good work.

First I must [rant] it is a shame to make a fast computer look slow [end rant].

I tried the changes on 4.4.3 where the kstyles/oxygen is in runtime instead of workspace, but I transposed successfully. I expected the menus to seem more "high performance" than they did.

There may be some delay other than the SubMenuPopupDelay ...
Referring to attachment, if one moves the mouse just slightly left of internet, the submenu disappears and the grey highlight clears. Then moving the mouse to the right, over internet, there is some moment while internet seems to gradually become highlighted and, then, submenu pops up. If one moves the mouse from one option to the other, say from internet to multimedia, then multimedia instantly becomes highlighted and there is a moment of the same length as if it had been gradually highlighting multimedia. There seems to be some kind of fade in/ fade out delay.

I verified that this does have an impact by testing with the 96 changed to 10 and the performance was slightly faster. I tested with the 96 changed to 600 and the performance was noticably more sluggish. With the 96 changed to 10, there can be flickering if the mouse is moved rapidly up and down the menu. It appears that the plastique (96) and cleanlooks (255) take the delay in qt.

I would be all in favor of allowing the user's "high performance sports car" to handle like a high performance sports car, even if it sometimes "does a wheelie", unless the user specifically chooses for it to handle like a schoolbus.

This is a great start.

Created attachment 47430 [details]
A config option instead of always delay 96

Let it be in ~/.kde/share/config/plasmarc
[SubMenuPopup]
Delay=96

Hi, 

Is this bug fixed or not? I am using KDE v4.5.1 on Kubuntu 10.10 (amd64) and have added the following two lines to ~/.kde/share/config/plasmarc.

[SubMenuPopup]
Delay=0

But that didn't work. There is still a short delay before submenus pop up.

no, it is still not fixed. I use the skulpture style for now, where the delay is configurable.

I have to check if Oxygen could respect the setting, because for KDE 4.6 it is no longer using KStyle.

*** Bug 268559 has been marked as a duplicate of this bug. ***

*** Bug 276429 has been marked as a duplicate of this bug. ***

Even with the skulpture style and the submenu delay cranked up to a full second, this does not work properly.

I will attach a picture that shows the problem.

Following the red path, even with the delay set to a full second will pop up a different submenu than they one wanted. If you can choose and click the desired item before the timeout runs out, then yes it works, but even if the mouse is out over the already opened submenu, if you have passed over any other submenu on the way there, the last submenu passed over will open up when the timeout expires.

What that means is that you must follow the blue path to explore a submenu. This is very difficult even for someone who uses KDE all day long. I watch my users struggle with this problem daily. It is very frustrating because it is not how other computer systems behave.

Created attachment 61320 [details]
desired path and required path for using submenu

Comment #20 looks like a Qt bug. If you are using Qt 4.7 (and Skulpture is compiled against Qt 4.7), please report to Nokia via http://bugreports.qt.nokia.com/secure/Dashboard.jspa

Opened Qt bug: http://bugreports.qt.nokia.com/browse/QTBUG-20094

I do not believe that Bug 276429 is a duplicate of this bug. It does not depend on the delay at all.

I guess it is a Qt bug, but one that is core to the way that KDE works. I am just surprised that no one else is frustrated by this strange behavior.

Okey, but you already reported it as QTBUG-20094, right? Or is bug 276429 different from what you reported to Nokia?

The link to the QT bug has changed to https://bugreports.qt-project.org/browse/QTBUG-20094

Looks like it is slated to be fixed in Qt 4.8.3 (if I'm reading that report right)

I'm happy I'm not the only one who is annoyed by this bug :)
BTW, GTK menus can be used as an example of how (from user POV) it should be implemented.

*** This bug has been confirmed by popular vote. ***

> I'm happy I'm not the only one who is annoyed by this bug

Which bug?

The delay for submenus not being configurable, or

the one reported in Bug 276429 where submenus are difficult to navigate to?

>Which bug?
I mean bug 276429 which appears marked as a duplicate of this one.

Created attachment 78778 [details]
example mouse-track

There is another problem, which is that submenus can vanish too fast, and we get the wrong menu!

I also like menus to appear and move snappily. But, sometimes one ends up in the *wrong* submenu.

In my diagram, I have opened the menu at  K->Applications->Development, and I want to lauch
Emacs. The obvious way to move the mouse is approximately along the green-line. 
But If I do that, I usually end up somewhere in the Electronics menu, no matter how fast I try to move the mouse pointer.

The only way to get to Emacs is to make a chess-knight's L-shaped move, which is quite counterintutive.

This problem also affects other applications, eg KWrite; it's not just the K-menu.

I suspect a heuristic is needed: 
 * submenu close-delay should be slightly longer than the submenu open-delay
 * if the mouse is moving quickly to the right as it moves down, don't swap the submenu for the
    next one.

I'm using KDE 4.10.2. Thanks for your time.