[Bug 24669] Re: Applications menu "lags" to refresh cache after installing new application

[Bogdan Butnaru]

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.

-- 
Applications menu "lags" to refresh cache after installing new application
https://launchpad.net/bugs/24669