|Summary:||make delay for showing submenus configurable (especially important for classic kmenu)|
|Product:||[Frameworks and Libraries] kdelibs||Reporter:||H.H. <cyberbeat>|
|Component:||kstyle||Assignee:||Maksim Orlovich <maksim>|
|Severity:||wishlist||CC:||alpeterson, andresbajotierra, b7.10110111, cfeck, davidtournaire, eshkrig, lucidlytwisted, missive, sb56637, tudon, zanetu|
|Latest Commit:||Version Fixed In:|
Plastique extension for less menu-delay
A config option instead of always delay 96
desired path and required path for using submenu
Description H.H. 2009-01-01 11:36:11 UTC
Version: (using Devel) Installed from: Compiled sources for me, the delay for submenus is much too high. I like them to show without a delay. It really feels sluggish now. And it's much slower than in kde3. It really would be good, to make this configurable in systemsettings.
Comment 1 Dario Andres 2009-01-01 13:49:29 UTC
Do you want this option for all the menus in all the KDE apps or for the classic KMenu application launcher only ? Thanks :)
Comment 2 H.H. 2009-01-01 14:07:36 UTC
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.
Comment 3 H.H. 2009-01-08 23:54:08 UTC
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.
Comment 4 H.H. 2009-04-10 13:08:31 UTC
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.
Comment 5 H.H. 2009-04-10 13:14:45 UTC
Created attachment 32740 [details] Plastique extension for less menu-delay have included binary to put in kde4-styles-dir
Comment 6 Christoph Feck 2009-12-10 02:08:05 UTC
*** Bug 140114 has been marked as a duplicate of this bug. ***
Comment 7 Christoph Feck 2009-12-10 02:09:03 UTC
*** Bug 167488 has been marked as a duplicate of this bug. ***
Comment 8 H.H. 2009-12-10 16:18:42 UTC
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
Comment 9 Christoph Feck 2010-03-14 16:20:40 UTC
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
Comment 10 H.H. 2010-03-14 17:19:41 UTC
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?
Comment 11 Zane Tu 2010-04-24 00:14:40 UTC
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/
Comment 12 linux fan 2010-05-25 21:15:44 UTC
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.
Comment 13 linux fan 2010-05-28 17:26:15 UTC
Created attachment 47430 [details] A config option instead of always delay 96 Let it be in ~/.kde/share/config/plasmarc [SubMenuPopup] Delay=96
Comment 14 Zane Tu 2010-10-21 21:40:10 UTC
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.
Comment 15 H.H. 2010-10-22 00:29:08 UTC
no, it is still not fixed. I use the skulpture style for now, where the delay is configurable.
Comment 16 Christoph Feck 2010-10-22 15:55:33 UTC
I have to check if Oxygen could respect the setting, because for KDE 4.6 it is no longer using KStyle.
Comment 17 Christoph Feck 2011-03-15 14:59:43 UTC
*** Bug 268559 has been marked as a duplicate of this bug. ***
Comment 18 Christoph Feck 2011-06-25 13:32:38 UTC
*** Bug 276429 has been marked as a duplicate of this bug. ***
Comment 19 missive 2011-06-25 14:29:21 UTC
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.
Comment 20 missive 2011-06-25 14:31:07 UTC
Created attachment 61320 [details] desired path and required path for using submenu
Comment 21 Christoph Feck 2011-06-25 14:49:25 UTC
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
Comment 22 missive 2011-06-25 22:54:31 UTC
Opened Qt bug: http://bugreports.qt.nokia.com/browse/QTBUG-20094
Comment 23 missive 2011-07-22 19:22:04 UTC
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.
Comment 24 Christoph Feck 2011-07-22 20:46:58 UTC
Okey, but you already reported it as QTBUG-20094, right? Or is bug 276429 different from what you reported to Nokia?
Comment 25 Twisted Lucidity 2012-09-14 08:34:38 UTC
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)
Comment 26 Ruslan Kabatsayev 2012-09-30 08:14:18 UTC
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.
Comment 27 Ruslan Kabatsayev 2012-09-30 08:14:31 UTC
*** This bug has been confirmed by popular vote. ***
Comment 28 missive 2012-09-30 23:40:11 UTC
> 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?
Comment 29 Ruslan Kabatsayev 2012-10-01 09:58:44 UTC
>Which bug? I mean bug 276429 which appears marked as a duplicate of this one.
Comment 30 Richard Neill 2013-04-10 17:19:38 UTC
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.