Bug 167488

Summary: submenus only open when not moving the pointer,and submenu delay is way too long in kde4.x
Product: kde Reporter: T. <tudon>
Component: generalAssignee: Unassigned bugs mailing-list <unassigned-bugs>
Status: RESOLVED DUPLICATE    
Severity: wishlist CC: alphakamp, cfeck, erikanderson3, jp7677, waissi
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Mandriva RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description T. 2008-07-26 20:05:43 UTC
Version:            (using KDE 4.0.98)
Installed from:    Mandriva RPMs
OS:                Linux

In all kde4 and other qt4 applications, on all versions of kde4 on linux as far as I could test.

The default sub menu behaviour gives the user an unnecessary feeling of slowness .

problem one: sub menus only open when one stops moving the pointer over a sub menu. If one keeps moving the pointer even over the sub menu it does not open unless one stops moving the pointer.

problem two: it feels like there is a bigger menu delay in kde4 then there was in kde 3.x 
especially in combination with "problem one"

It does not seem like the best default behaviour, as it gives users an unnecessary sluggish menu feel.
I think it should be changed if possible.

It would be nice if such things could be easily configurable somehow.
Comment 1 jos poortvliet 2008-07-27 17:20:21 UTC
I think this isn't as noticeable as it could be due to the bad driver situation - all menu's are pretty slow. But the moving thing is weird.

I can see why there needs to be a submenu delay - in some situations (for example with the copy-to submenu in konqi/dolphin) its needed to prevent menu's from popping up too soon. It probably should be configurable, though.
Comment 2 jens 2008-11-15 22:49:20 UTC
Abou problem #1: this bug is caused due to this issue in QT:
http://trolltech.com/developer/task-tracker/index_html?method=entry&id=164725

This is actually a real showstopper for me for using the otherwise very excellent KDE4. I'm using a wacom tablet and it is almost impossible to hold the pen completely still until the the submenu pops up :(

Does anybody has the contacts to vote for a solution at Trolltech?
Comment 3 Sami Järvinen 2008-11-22 23:46:56 UTC
I can't make myself use KDE4 because of this bug. The classic K-menu is especially painful to use. I'm very surprised this gets so little attention from people.
Comment 4 jens 2008-12-01 21:18:41 UTC
For the record, I'm using a wacom Intuos 3 tablet and I just found out that using

Option	"Suppress"	"15"

in my xorg.conf improved the situation a lot. Still not perfect, but much better.

Regards, Jens
Comment 5 alphakamp 2009-03-19 16:47:19 UTC
(In reply to comment #0)
> Version:            (using KDE 4.0.98)
> Installed from:    Mandriva RPMs
> OS:                Linux
> 
> In all kde4 and other qt4 applications, on all versions of kde4 on linux as far as I could test.
> 
> The default sub menu behaviour gives the user an unnecessary feeling of slowness .
> 
> problem one: sub menus only open when one stops moving the pointer over a sub menu. If one keeps moving the pointer even over the sub menu it does not open unless one stops moving the pointer.
> 
> problem two: it feels like there is a bigger menu delay in kde4 then there was in kde 3.x 
> especially in combination with "problem one"
> 
> It does not seem like the best default behaviour, as it gives users an unnecessary sluggish menu feel.
> I think it should be changed if possible.
> 
> It would be nice if such things could be easily configurable somehow.

(In reply to comment #0)
> Version:            (using KDE 4.0.98)
> Installed from:    Mandriva RPMs
> OS:                Linux
> 
> In all kde4 and other qt4 applications, on all versions of kde4 on linux as far as I could test.
> 
> The default sub menu behaviour gives the user an unnecessary feeling of slowness .
> 
> problem one: sub menus only open when one stops moving the pointer over a sub menu. If one keeps moving the pointer even over the sub menu it does not open unless one stops moving the pointer.
> 
> problem two: it feels like there is a bigger menu delay in kde4 then there was in kde 3.x 
> especially in combination with "problem one"
> 
> It does not seem like the best default behaviour, as it gives users an unnecessary sluggish menu feel.
> I think it should be changed if possible.
> 
> It would be nice if such things could be easily configurable somehow.

I experience this also, to the point sometimes where I can't move the mouse for several seconds.  I'm still looking for a bug report but I also now have 100% cpu usage with process kded4 upon first logon.
Comment 6 Erik Anderson 2009-05-01 17:51:20 UTC
Confirmed as well in KDE 4.2.2, as installed on Ubuntu Jaunty (9.04).  

I also use an Intuos 3 Wacom tablet as my primary "mouse", and this menu lag issue makes KDE practically unusable.  In fact, I couldn't get any submenus to appear at first, and I had given up on finding out where they went and was about to file a bug report stating that submenus were flat-out broken, when I found this bug report instead.  

This doesn't happen under Gnome, nor under Windows.  

The problem is not just with the KDE launcher menu, but with *ANY* submenu in *ANY* KDE program.  Running a Gnome program such as Synaptic in a KDE environment, for instance, does not exhibit this issue.  

Could someone please change the "Status" to "CONFIRMED", and the "Severity" to at least "Normal"?  Calling this an "unconfirmed" "wishlist" item is actually kind of insulting to those of us facing this issue, given the very real and severe usability impediments it presents.  

Until this is fixed, I'm going to have to switch back to Gnome, simply so I can get some work done.
Comment 7 Erik Anderson 2009-05-01 17:55:47 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Christoph Feck 2009-05-26 21:58:32 UTC
Skulpture style fixes that bug: http://kdepepo.wordpress.com/2009/01/05/skulpture-022-released/
Comment 9 Erik Anderson 2009-05-27 17:55:43 UTC
Fascinating that a style can work around this Qt 4 bug.  Any word on getting this fixed in Qt 4 itself?
Comment 10 Christoph Feck 2009-06-04 15:52:22 UTC
If everything works well, that bug will be fixed in Qt 4.6 (nothing official, I just monitor qt/master for changes :)

http://qt.gitorious.org/qt/qt/commit/a04e1c4733feb643eb8da7b4a94c175153691b38
Comment 11 Christoph Feck 2009-12-10 02:09:03 UTC
The bug is fixed. What remains is the sub menu delay.

*** This bug has been marked as a duplicate of bug 179267 ***