Menu items disappear while the menu is open

Important, we shouldn't be rebuilding the menu on updates. We should be smarter about how we handle it.

Adding aytana-design because I think it'd be good to get some design feedback on this. It seems like leaving the menus in an inconsistent state isn't good, but the update while browsing sucks too. Not sure of how we should handle this? Only update when your mouse is over a separator? Block clicks for a second when we update?

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.

The only thing I can see is that there's probably some odd cases where the menu expands to be larger than the screen, and thus gets scroll items on either side of it. I guess in those cases we just need to ensure that the item under the mouse stays constant. Need to test to ensure that's the case.

Another implication of changing menu items while the menu is open became apparent in bug 883317: menus of the indicators can go offscreen if menu items with long labels are added.

This is a toolkit problem, not a DBus Menu problem. It has nothing to do with window menus or indicator menus specifically -- It might equally happen in combo box menus, context menus, or any other kind.