GNOME "Main Menu" panel applet slow to open on first click (NOT compiz related)

seems to be slow especially after a change in the content of the menu here. BTW
I've opened a bug upstream about this;
http://bugzilla.gnome.org/show_bug.cgi?id=164574

that should be fixed with this upload.
an upstream patch to fix this issue is in this upload:

 gnome-panel (2.9.91-0ubuntu3) hoary; urgency=low
...
   * debian/patches/02_menuspeed.patch:
     - patch to speed up the menu opening (Hoary: #5643).

Upstream's comment:
"Another approach. This might be better... or not. With this patch, please pay
attention to submenus. Are they slow to appear or not?"

no reply, bug closed. Feel free to reopen if that's still an issue.

This problem is still alive and kicking in Dapper with the latest updates (gnome-panel_2.13.91-0ubuntu6_i386.deb). The first time the 'foot' menu is opened it takes several seconds to appear. Meanwhile the panel or the menu applet has grabbed the X server so I can not do anything else but wait for the menu to appear. Irritating to say the least.

feel free to comment on the GNOME bug if you want to work with them at making it faster

It is still SLOW on Gusty beta.

Obviously I am referreing to the "Ring" button (not the menu with "Applications", "System", but that one with all those in one)

Reopened the bug (it's still present in 2.20) and updated with the bug Trapanator filled in bugzilla.

Confirmed in my boxes (feisty and gutsy)

Gnome bug was a duplicate. Updated with the correct one.

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.

According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates

The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage

+1 on this.

The bugzilla patch is from 2005, it doesn't look like the fix has been commited to gnome: gutsy still has this problem, two years after; here's a workaround i found googling:

http://www.marksanborn.net/linux/speed-up-the-gnome-menu-and-fix-the-annoying-icon-delay/

Ari, no the bug is still open upstream, feel free to comment/send the patch there, thanks you.

Bug still present in Hardy Alpha 6.

Is this related to bug #108951 "Gnome drawer applet delays and unresponsiveness" ?

Andrew: I don't think it is, please see my comment in #108951. Thanks.

The same problem appeared in Hardy stable release

+1
The problem occurs in hrady. in all menus including submenus. right click menu is slow as well in almost all programs includign firefox(which i use the most). if theres a fix can someone please let us know

Found out that this happens only when compiz in enabled and nvidia twinview is enabled.

works fine when i type "metacity --replace"

I use no compiz nor compositing metacity in hardy. The problem persists.

I have the same problem:
While default "Menu bar" applet is very responsive to clicking
all the time, first click on "Main menu" after login takes a while..

I have this bug too. It is exactly as Roman describes it. Worst case, it can take 15 seconds before the menu pops up. It should be pre-loaded, as I guess the "Menu bar" is. To fix this bug, just handle it exactly the same as the Menu Bar.

I'm testing Intrepid alpha 6 and the problem persists. When hit the main gnome button, thats the ring button that contains all applications, system and places.... it takes almost 3 seconds in load the menu... it accsess the hard drive when loading

I can confirm the bug in Intrepid release using gnome-panel 2.24.1. This post suggests rebuilding the icons cache -- http://www.marksanborn.net/linux/speed-up-the-gnome-menu-and-fix-the-annoying-icon-delay/. However, even when I update the cache, after a logout and successive login the problem persists.

When can you fix this boring bug? It's up from 3 (THREE) years...

zzzzzzzzzzzz

Annoying bug for me too. For too long.

I was able to solve the problem by changing the fade mode setting on the Fading Windows plugin so it uses the Speed setting instead of the Time setting. I have no clue why it does this, but it solved the problem for me.

Knifa, from what you said, it sounds like you are using Compiz. Do you know if there is a way to toggle the same effect if I am using metacity.

Metacity doesn't have any effects like window fading, so I'm not too sure. When I switched to Metacity, everything worked fine. It was only with Compiz I got the ridicously slow loading times.

The root cause of this bug has nothing to do with Compiz, Metacity or any window- or compositing-manager so bringing those into the mix only serves to muddle the issue.

The first time the menu button is clicked Gnome starts searching high and low for menu entries, accompanying icons and such. It is this search which takes time. A possible solution to this problem would be for Gnome to do this search in the background at a low priority (so as not to impede anything the user might want to do once the desktop has appeared) when the system is first started in the hope that it is ready once the user decides to click on the menu button. If said user immediately presses the menu button he'll still have to wait for the thing to load but that can not be helped - yet.

As to who will ever implement something akin to what I mentioned, who knows? I don't really use the menu as the hacked version of good old mini_commander (no system-hogging deskbar nonsense for me...) is much faster but maybe I should look into it anyway.

I have the same problem with Hardy and Intrepid. I think the problem is in the mini menu of gnome applet. In the normal menu works perfectly.

This problem STILL! exists in Intrepid.

It has been an active bug for something like 3 years now.

Does anyone have a fix for this frigging annoying bug? I've tried everything, with no luck.

The round menu (when it replaces the menu bar) takes up to 15 seconds to register a click. After it has been clicked once, it is fast from then on.

Just installed Jaunty Beta 1. This bug _still_ exists here.

Same bug as way back in Breezy, when I first saw it. Perhaps the oldest bug in Ubuntu - except for bug 1??

If this is a caching of the icons problem (most common reason I hear) then why isn't it a problem for the gnome menu-bar (applications - places - system menu)?

I think the solution would be found with finding the reason why the menu-bar doesn't have a caching problem and implementing the same solution for the menu-button.

After installing the package 'xautomation' I used the following command in session startup:

 xte 'mousemove 10 1040' 'mouseclick 1' 'usleep 100000' 'mouseclick 1' 'mousemove 700 525'

This simulates two mouseclicks over the menu icon (open and close) with a short delay (0.1s) in between and moves the mouse back to the centre of the screen. If you have a smaller screen than 1400x1050 you will have to adjust the coordinates.

Since I put this in session startup the menu opens without delay as it has already been opened at startup.

However, this is a dirty workaround and a real fix would be greatly appreciated.

Here's another version of Karl Martin's workaround, except mine uses xmacroplay. Remember to adjust the coordinates to that the click doesn't miss your Applications menu.

echo -e "MotionNotify 920 10\nButtonPress 1\nDelay 1\nButtonRelease 1"|xmacroplay :0.0

The all-in-one menu of GNOME still loads slow in Ubuntu Jaunty, it takes several seconds to open the menu for the first time on a modern machine.

Confirmed in current Jaunty.

- Unfamiliar users click multiple times while waiting. When the menu finally shows up, it's immediately hidden if the number of clicks was even. Users perceive that they can't open the menu.
- It is utterly annoying, results in bad user experience.

Isn't this problem easy to fix by simply following the same mechanism as in "menu bar" applet?
So shouldn't this bug be part of One Hundred Paper Cuts?

This annoying bug is still present in 2.6
Hope One Hundred Paper Cuts will fix this.

the issue is not a papercut one

bug is still here looks like it came to stay with us 4 ever..;-)

I reproduced this bug on Jaunty which was upgraded from Hardy and Intrepid.
But I just made a fresh install of Jaunty， I never meet this bug till now.

Sorry, I made a mistakes, it has no relation with the upgradation.
"Menu Bar" works fine. "Main Menu" is pretty slow at its first click.

Yep, mine as well, BUT it only happens with Compiz activated. Maybe this should be investigated...

Great job, guys'n'gals =)

Still a problem in karmic, surprise surprise? ;)

But I did want to add in response to comment #42 that I am not using compiz.

hi,
after long waiting, today I tried again the menu icon. I have been amazed at see that the delay is fixed. I try it with karmic beta.
someone else can test?

Dell inspiron 1720
gnome-panel 1-2.28.0-0ubuntu03
Linux USBK01 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:06:40 UTC 2009 x86_64 GNU/Linux

thanks in advance.

The problem is still there in Karmic as far as I can tell.

Yep, the problem is still alive and kicking. Just opened the menu, it took 25 seconds to appear...

one more with karmic to report :P

the problem disappears turn off compiz

No, turning compiz off does not fix the problem. Verified just this morning.

(glad mine doesn't take 25 seconds at least)

As I already stated in #28 this bug has *nothing* to do with compiz, compositors, window managers or anything else of that sort. If turning off compiz changes something you should file another bug for *compiz*.

It's true. Turn off compiz don't solve the problem. Sorry

2009/10/20 knarf <email address hidden>

> As I already stated in #28 this bug has *nothing* to do with compiz,
> compositors, window managers or anything else of that sort. If turning
> off compiz changes something you should file another bug for *compiz*.
>
> --
> GNOME "Main Menu" panel applet slow to open on first click (NOT compiz
> related)
> https://bugs.launchpad.net/bugs/12040
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Desktop panel for GNOME: In Progress
> Status in One Hundred Paper Cuts: New
> Status in “gnome-panel” package in Ubuntu: Triaged
> Status in gnome-panel in Ubuntu Gutsy: Invalid
>
> Bug description:
> Hello,
>
> The new gnome menu is slow to load compared to Warthy. The first time I
> click on
> menu it begins accesing the hd and after some seconds appears. This was
> faster
> on Warty as I said. It seems that almost all menus are loaded the first
> time.
> This is confusing for the user.
>
> I'm probably experiencing longer delays than other users because I'm
> running
> Ubuntu on a laptop (which has a slow HD).
>
> SnOp
>
> http://bugzilla.gnome.org/show_bug.cgi?id=164574:
> http://bugzilla.gnome.org/show_bug.cgi?id=164574
>

I can confirm this in Hardy and Karmic.

VERY annoying bug. More noticeable on a laptop than a desktop as laptops are turned on and off so often; laptops are also slower to find and show the icons.

I tried Karl Martin's xautomation fix but it didn't work, possibly because the menu isn't yet loaded on the screen when the click is performed.

As per

Karl Martin

"After installing the package 'xautomation' I used the following command in session startup:

 xte 'mousemove 10 1040' 'mouseclick 1' 'usleep 100000' 'mouseclick 1' 'mousemove 700 525'

This simulates two mouseclicks over the menu icon (open and close) with a short delay (0.1s) in between and moves the mouse back to the centre of the screen. If you have a smaller screen than 1400x1050 you will have to adjust the coordinates.

Since I put this in session startup the menu opens without delay as it has already been opened at startup.

However, this is a dirty workaround and a real fix would be greatly appreciated."

I added sleep time before xte line and saved as a exec'ble file and used " sh 'path to file' " with out quotations in startup applications and trick worked.Thanx

eg:
sleep 5
xte 'mousemove 1275 10' 'mouseclick 1' 'usleep 100000' 'mouseclick 1' 'mousemove 700 525'

mine is 1280x1024 and menu is located top right.You might want to adjust sleep time according to needs(its in sec's)

For me, the delay is unappreciated, less than a sec (~ 0.5s). I think the next will improve the behavior:

I've edit (create) ~/.gtkrc-2.0, adding

             gtk-menu-popup-delay = 0

I'm sure that there is no problem when you have "Menu Bar" loaded into the panel too, so you can put the "Main Menu" next to the "Menu Bar" and you will see Ubuntu logo twice. But if you want to have the "Main Menu" alone (like i want) the problem will persist.

So the problem is not gnome-panel neither gnome-menu-bar, it's gnome-main-menu.

I suppose that if you have a theme with large icons or similar, the time to load them will be bigger.

I hope this will be for help.
Sorry for my English.

I have the .gtkrc-2.0 tweak but the problem still exists. I don't think the tweak has any effect at all on the problem. As a side effect do you notice the right click menus being slow to load as well?

I just noticed for me the other applets are also running slow. For example I have Tomboy Notes and when I opened the Manage Notes window I noticed that it's menus were acting slow too. Therefore I think all these things are linked. The GUI interface (not sure what it is) eg gtk, qt... is the thing causing problems. We need to find out what GUI it is and try to reinstall it or use a newer version to see if that will fix the slow menus.

Confirming on Ubuntu 9.10 on 3 different machines, using the Main Menu applet instead of the default custom Menu Bar.
My current work-around is to install xvkbd and add the following to Startup Applications:
sh -c "sleep 5 && xvkbd -text '\A\[F1]' && xvkbd -text '\e'"

This will load the menu with Alt+F1 and then press Escape to close it right away. The sleep is necessary because sometimes the menu isn't available early, and the value is a trial and error heuristic that varies between 2 and 5 seconds from machine to machine.
It's similar to the work-around posted by las, just using xvkbd instead of xte to send events.

The bug is annoying because "non-techy" users usually greatly prefer the single-icon Main Menu to the default bar... and often one of first things those people remark is how slow Ubuntu is after clicking on the menu for the first time.

FWIW, I've been testing lucid, and there seems to be caching of the menu now that makes this a non-issue for me.

There are some issues with the cache not being refreshed properly on occasion, but that is a separate problem. :)

I think it is good idea to add some "wait cursor" to show that menu is currently generating.

More information is avilable at:
https://bugs.launchpad.net/ubuntu/+source/gnome-main-menu/+bug/527594

What do you think about this idea?

IMO it's always good to give users a way to know that the task is in process. IMO a "wait cursor" is the very least that a users should see when a task like this is in progress.

J.M. "Peng" Hardin wrote:
> IMO it's always good to give users a way to know that the task is in
> process. IMO a "wait cursor" is the very least that a users should see
> when a task like this is in progress.
>
>
Wouldn't the time be better spent fixing the problem?

After switching my hard disk to a solid state disk (Intel X-25M G2) this bug disappeared. This supports the assumption that the delay is caused by accessing lots of files on the hard disk as a task like this benefits considerably from the low access times of a solid state disk.

This bug was submitted 5 years ago. So I think it will be not resolved so fast.

I suggest to add some aditional information during first click ("wait cursor").
It is very easy to add this feature.

I think it will be very useful for beginner user, for example my friend who installed Ubuntu and he thought that Ubuntu freezed.

I am also able to confirm that on 10.04 desktop and netbook this problem is present. It's very noticeable on older 4600 and 5400rpm drives where you can wait up to and even over 35 seconds for it to appear.

A non-programmer solution to this problem would be to have the menu stored in a cache along with the icons, and this gets refreshed when a program is installed, as this would help prevent the random reads to the drive, most likely trying to fetch the icons. - This may not be correct, it just seems to be what is happening.

There is a work a round http://ubuntu-virginia.ubuntuforums.org/showthread.php?p=7909455 this would suggest that Kris Douglas is correct.

running maverick, main menu still takes about 7-10 seconds to open after any boot-up or reboot.

I do not like most Microsoft Windows OSs or apps.

I do like the start-up menu, it's fast and changed or edited like any other shortcut links, and even on the fly.

Why not use what works best, and is enjoyed by millions of user.

Apparently I made somebody angry, because they subtracted from karma, which I do not believe in, in the first place. - Open source should also allow for open mind.

I believe in fast & stable apps & intelligent, logical programs.

The Main Menu in Ubuntu has way to many flaws, & that for many years now.
It has not kept up with modern improvements, as the rest of Ubuntu. - Examples:

1.) It takes longer to open, then log-out, log-in, or warm boot back to Maverick. -
        Main Menu should auto-start, & be ready to use as soon as the desktop is fully on the monitor!

2.) "Edit Menus" function is unbelievably slow, awkward, agonizing & archaic, only one item at a time can be
         moved, some items refuse to move all together; icons are missing at times, & can take many minutes to
        manually find, since someone has removed the icon viewer which was a wonderful app.

3.) The more one tries to edit the Main Main, the more does the program fight one, until it totally refuses to
        work correctly.

4.) One finally gives up, & ends up with sky high menus, which when they get too high must be scrolled, except,
         that the items on the bottom of the scroll cannot be selected, unless one presses & holds the <Ctrl> key
         & uses the mouse at the same time.

Main Menu does not just have bugs, it really needs to be replaced to become an easy, modern app, that will improve the Ubuntu experience, a really open & friendly menu that will snap to the needs of the modern user.

[sorry, but no attachment or patch can truly fix the archaic Main Menu, I stand by my comment of 2011-02-13.]

I have confidence, that the Ubuntu Masters can revolutionize a menu better then any other OS.

BavarianPH,
Ubuntu Forever!

@BavarianPH: it seems that there are people in the project who interpret any negative statement about Ubuntu, or any positive statement against one of its 'avowed enemies' as 'heresy' and use that to 'punish' the 'heretic' who dared to utter it. This happens in the forums - which I no longer use since the forum moderators are part of the problem - and seems to happen here as well.

This is counterproductive and sad. Free software in general, and Ubuntu in particular should be approached with an open mind. If something does not work as it should it needs to be changed. If some other program - whether it be open or proprietarty, free or fee does not matter - does it better it should be possible to state this without being accused of heresy, punished by forum gods or demoted by some arbitrary measure.

Interestingly, in natty-alpha3 & newer,

the gnome-panel Main Menu comes up instantly,

scrolling works well, only editing remains tedious.

Of course natty uses the unity-panel-desktop-and so on.

& may not be fully integrated with natty?

So gnome-panel must be added to auto-start,

& then add the menus and applets of ones choice.

BavarianPH,

Ubuntu Forever!

In natty-beta2 this problem is present :-(

With "Main menu" + "Menu bar" in the gnome panel is well ¿?¿?