Version: (using KDE KDE 3.1.3) Installed from: SuSE RPMs OS: Linux Moving the mouse-cursor up and down is significant slower than in its submenus or just any other menus in kde-applications. Even in a big Bookmark-Menu, the moving of the cursor (or selection of the Menu-Entries) is much much slower. I noticed that on my PIII 450 MHz machine, BUT, it is possible, that on faster computer, you are not aware of this anoying behavior. So please check it out on slower machines ;) It seems, that there is a kind of "delaying" implemented that was used to delay the opening of submenus but, as i said, it looks as if something like that is slowing down the Kmenu (only the main-kmenu). This bug gives a feeling like the system is really slow!
This might be an old Qt bug. Which Qt version do you have installed?
Hi, i am using this qt: >rpm -q qt3 >qt3-3.1.2-54 >rpm -q qt3 >qt3-devel-3.1.2-54
this is intentional. each submenu gets filed with its items when it is shown. this causes a small slowdown in showing the submenu, but also means that the whole K menu doesn't have to be set up when you first click on it. on many systems, there are so many items in the K Menu that on slower systems it would cause a delay of several seconds before the K Menu would show. obviously, this is even worse than a tiny delay on the submenus. of course, once a submenu has been shown once, it doesn't need to be initialized again and is as fast as any other menu.
Sorry, but you didn't get my point. > each submenu gets filed with its items when it is shown. :this is ok. > this causes a small slowdown in showing the submenu, but also means that the > whole K menu doesn't have to be set up when you first click on it. :this is also ok. this is usual smart programming. > on many systems, there are so each submenu gets filed with its items when it > is shown. :sure. that's also ok. > this causes a small slowdown in showing the submenu, but also means :sure, this is ok. but i didn't mean this kind of slowdown. > that the whole K menu doesn't have to be set up when you first click on it. :that is also correct. good programming, but this is also not the problem!.. > on many systems, there are so many items in the K Menu that on slower systems > it would cause a delay of several seconds before the K Menu would show. :yes, i also notice that, if my harddisk is busy with anything else, BUT :THIS is also NOT the problem that i was talking about in this bug-report. > obviously, this is even worse than a tiny delay on the submenus. :hm, this is not so worse, people could remove or manage the number of :Kmenu-entries. i.e. SuSE's modified Kmenu doesn't have got too much entries. :BUT, the number of entries and the delay of popup the Kmenu is ALSO NOT the :bug i am talking about. > of course, once a submenu has been shown once, it doesn't need to be > initialized again and is as fast as any other menu. :sure, that is logical. My situation is this: - Kmenu (popup) is shown fast. (if it is previously loaded, anyway THIS is not the point!) - submenus (popup) are shown fast (if they are previously loaded, anyway, THIS is not the point!) - moving_the_mouse_over Submenus is fast. (it should be fast even on a PI 200MHz! ;) now.. i will tell about the BUG. - moving_the_mouse_over the Kmenu (menuitems) is SLOW. and there is actually no reason for that instead of a bug. (every submenu could have hundreds of submenus or Menuitems, just like my Bookmark Menu without any problems!) (again, popup doesn't matter at all, even the popup of my Bookmark Menu is fast once it is loaded.) greetings, manni
some more details: actually not the _mouse-moving_ is slow over the Kmenu-items, but the _selection_ of the menuitem under the mouse-cursor is slow, really TOO slow. that is very anoying. actually my machine should really not too slow for that, and, the PROOF are all other (even very big) Menus/submenus/popupmenus. manni
well, on my PII 400 here it is no different than any other menu on the system, save for the submenu delayed loading, which is, of course intentional. i simply don't see the effect you are concerned about... if i understand what you are saying, when moving the mouse over the menu the highlight showing that the menu item is currently selected lags or is slow?
Subject: Re: Moving Maus-Cursor over Kmenu Items is significant slower than in any other (big) Menus or submenus of Kmenu! > if i understand what you are saying, when moving the mouse over the menu > the highlight showing that the menu item is currently selected lags or is > slow? yes, i mean exactly that. (moving the mouse over the menu, highlighting of menuitems (while still moving the mouse) is very very slow, but only in the Main-Kmenu. all other menus (or submenus) even with many menuitems are fast :(
Was about to file the same bug report.. but I did some investigating and I tracked it down to the display of the sideImage (NOTE: I'm using 3.2beta1). If you disable 'Show side image' in the Panels configuration, then it works like any other menu. It appears that when the side image is enabled, the image is completely repainted whenever you move the mouse (ie. whenever a paintEvent occurs). The code is located in: kdebase/kicker/ui/k_mnu.cpp: void PanelKMenu::paintEvent(QPaintEvent *e) I guess this is something for 3.2.1 ?!
*** Bug 66089 has been marked as a duplicate of this bug. ***
Subject: Moving Maus-Cursor over Kmenu Items is significant slower than in any other (big) Menus or submenus of Kmenu! YEAH ! Exactly, the rendering of the side-image is the problem, i switched it of, and the KMenu is as fast as any other menu, finally :) i HOPE it will be fixed soon, well, at least for 3.2.1 Thanks Am Mittwoch, 19. November 2003 15:18 schrieb Karl Vogel: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=63865 > > > > ------- Additional Comments From kvo--kde@seagha.be 2003-11-19 15:18 > ------- Was about to file the same bug report.. but I did some > investigating and I tracked it down to the display of the sideImage (NOTE: > I'm using 3.2beta1). > > If you disable 'Show side image' in the Panels configuration, then it works > like any other menu. > > It appears that when the side image is enabled, the image is completely > repainted whenever you move the mouse (ie. whenever a paintEvent occurs). > > The code is located in: > > kdebase/kicker/ui/k_mnu.cpp: void PanelKMenu::paintEvent(QPaintEvent *e) > > > I guess this is something for 3.2.1 ?!
Here I have Mandrake 9.2 with KDE 3.1.3 and Keramik as default style, colors. My system configuration is: PIV 1.7GHz, 196mb ram. I really hate the slow highlight of menu items in Kmenu. the poster meant that highlight of menu items is delayed, not the popuping up of submenu. I suggest that the popping of submenu to be configurable. I like quick popping menus. here are the steps to see the Slow Highlight of Menu items: 1. Click on KMENU 2. Quickly move your mouse pointer over every menu items up and down (from Applications to Shutdown and vice-versa) 3. You can see that mouse pointer is moving faster than the selection (highlight) is being done. 4. this makes me feel that i am using a 486 pc :( so does openoffice 1.1 :(
Especially in a network X-session this gives a sluggish feel to the menu, it's also a good way to better see the effect... (for all those that suffer of fast machines ;-)
*** Bug has been marked as fixed ***.