Better menu item injection

[pgaskin]

The current method is simple and reliable, but somewhat inflexible. Also see #42.

[pgaskin]

Basically, my current idea is to:

• Hook the menu item adding function like it is done currently, but instead of adding items, add a signal handler for aboutToShow (alternatively, we could hook the signal itself and check the QObject name or actions to identify which menu).
• In the signal handler, check if the latest config has been applied. If not, loop over the actions, and remove all items and separators with the custom property NickelMenu set to true). Then, find the action we're appending stuff after, and insert out actions after it.
• To replace the config, we parse the new one, then swap the pointers and free the old one (note that this should be safe since we're replacing the menu item handlers before the menu opens).

[pgaskin]

This also has another advantage: we can remove any menu item we want without having to intercept it's creation. If this idea works, I'll probably add a feature to hide arbitrary items (menu_item_hide:<loc>:<translated_label>).

[pgaskin]

There are a few tricky things with implementing this:

• Actions can't be reordered once inserted without reinserting, but removing the item may also delete it if it's owned by the menu (I don't think nickel does this, as it uses it's own wrappers rather than directly calling addAction, but I'll have to check [but if they happen to decide to call addAction directly one day, we won't have to deal with the next point anymore]).
  • Update: It seems that only clear will delete the items, but not removeAction. This means we should be fine if we just call removeAction on each (and if anyone's wondering about what happens if Nickel has a pointer to the action and still uses it afterwards, the object is a reference, not a value, so it will still work fine).
• We can't build the item manually without losing cross-version compatibility and stability (or adding a whole lot more code) because AbstractNickelMenuController::createMenuTextItem deals with the touch gesture stuff for us. So, we need to insert the action, then remove and reorder it later (and this at least won't run into the aforementioned issue since the actions are created externally).

I'm going to start actually implementing this later today.

[pgaskin]

Hiding actions won't be possible with additional work because MenuTextItem has its own text getter/setter, and doesn't use the one from the QAction itself.

[pgaskin]

Another option might be to use AbstractNickelMenuController::createMenuTextItem, but deal with separators manually. Then, we wouldn't have to remove the existing items and re-add them again.

[pgaskin]

The best (in terms of compatibility and simplicity) thing to do, although it isn't the most efficient, is probably to use createMenuTextItem, but immediately remove the added action and put it in the right spot, and handle the separator manually so we don't have to move it as well.

[NiLuJe]

A QAction has a "visible" state than can be toggled. Could we somehow rely on that, or is this lost in the Nickel implementation?

[pgaskin]

A QAction has a "visible" state than can be toggled.

But what would that be for?

[NiLuJe]

Well, hiding a menu entry ;).

[pgaskin]

Well, hiding a menu entry

The issue isn't so much hiding it as being able to add them to an arbitrary location when the menu is opened rather than when the menu is being initialized.