Applications menu "lags" to refresh cache after installing new application

Thanks for your bug. Basically the menu is regenerated on changes, there is no
other way to do... Vincent, are you interested to get this bug upstream? Is
there any plan to change that?

Hrm. This could be useful to have upstream, but maybe only as an enhancement.

I've forwarded it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=321792

I couldn't open the link to upstream, not sure if it's a temporary problem.

This and bug #44002 are probably instances of the same problem: the first time the menu is displayed, and after a change, it is completely regenerated. It looks very bad, because it feels like the whole interface froze. (It doesn't, but since the user's focus is on the menu, it seems that way.)

I know the menu is regenerated on changes, but there's no need to regenerate the entire menu. Most of the time there's only one or two entry added/removed. The menu should be displayed from the cache, and only the changed items should be modified.

Even more, usually the change is in a sub-menu, so we might have time to add/remove it before the user reaches it. Anyway, removing or adding an entry after the menu is displayed would be much less annoying than having the whole menu freeze for five seconds or more.

Another idea would be to monitor the directories in the background when possible (there's a kernel extension for that) and add the entry even before the user clicks the menu.

The delay also appears when the user clicks for the first time the menu, _each session_. Someone said fixing this would add a startup delay, but that's wrong. The right way is to cache the last-used menu (before the shutdown), and do just an incremental update at start-up.

Second, we could populate the menu in the background, on a low-priority thread. This way the start-up is not greatly affected. (And the system is a bit unresponsive at the start, anyway, so the menu wouldn't be noticed.)

Since dual- and multi-core processors are more and more common, parallel start-up should be much more often used.

The gnome bugzilla had problems today, that's fine now

the bug should be fixed in hardy, feel free to reopen if you still get the issue though