Comment 3 for bug 412797

What a deliciously tricky problem.

A brutal way of handling it would be never to change menus while they're open. But there are at least a couple of worthy use cases for updating them: the items for available wireless networks in the network menu, and search result items in any menu containing a search field.

Going to the other extreme, a surgical solution for Cody's specific problem would be: If any item is highlighted at the moment it is supposed to disappear, it should become insensitive instead, and then disappear once it is no longer highlighted. However, that would be a bit *too* surgical. For example, if you are over item N that is pending deletion, and you aim at item N+1, you'll end up clicking item N+2 by mistake, because item N+1 has just slid into where item N was. It also doesn't help the opposite case, where you try to click item X, only to click item X-1 that appeared above it a moment earlier.

So, we need something between those two extremes. How about this:
(a) Whenever the highlighted item in a menu is supposed to disappear, it should instead become insensitive until it is no longer highlighted, and disappear then; and
(b) whenever any item X is added to or removed from a menu, the set of items {S} should become insensitive for one second, temporarily overriding any other changes in sensitivity for those items in that second:
    - if the menu opened downward, {S} = X + all items after it
    - if it opened upward (e.g. from a menubutton near the bottom of the screen), {S} = X + all items before it
    - if it opened in both directions (i.e. an option menu), {S} = all items in the menu.

Are there any obvious cases where that would fail? As you might guess, I think this is something that should be handled in GTK for every menu, rather than in DBus Menu just for indicator menus.