Extensible context menus

[Andreas Pakulat]

Hi,

the recent mail from David (thanks for kicking me) made me think again
about how we currently provide extensible context menu. 

Currently each plugin can contribute by overriding a virtual method and
then provide a name and list of actions, which results in a submenu
entry in the context menu that has the given name as title.

Now this works quite well for plugins that only need to be in "their
own" group, however there are some plugins for which it makes a lot of
sense to have multiple groups. One example is the project management
view, this plugin should provide renaming/moving files in a project, as
well as building and configuring a project. And the former actions are
pretty much separate from the building and should be in a submenu like
"refactor" as thats really what it does.

So I'm currently trying to think about how we get really extendable
context menus, where a plugin can contribute to existing submenus as
well as top-level menu items and its own new submenu.

Something that came to my mind is having a small structure like:

class ContextMenuContribution 
{

public:
  /** user visible string for the submenu */
  QString subMennuName();
  /** id to uniquely identify the submenu */
  QString subMenuId();
  /** list of actions to append to the submenu */
  QList<QAction*> actions();
};

And then a plugin would simply return a list of such instances. We could
either have an id of "ContextMenu" for adding the actions to the context
menu, or use an empty id to do that.

One problem I see with this is order of actions. Basically the order of
the actions might change after each start of kdevelop, as other plugins
might get loaded that might contribute to an already populated menu.
Ideas how to solve that?

Another option would be a bit more complicated. Let the plugin that
actually own the view (in which a context menu is requested) handle the
actions. That means, upon context menu request, the plugin asks the
plugin controller to fetch a list of contributions to the context menu
(using the above structure). Then this plugin adds its own actions into
the menu as it would like and takes the list of contributions and adds
them at the end. This doesn't completely solve the problem of
action-ordering, however I think it reduces them quite a bit. We could
even think about adding groups inside menus, so we'd have something like
a "edit" group, a "navigate" group and a general "additions" group for
project items in the project manager.

Andreas

PS: In case anybody notices: Yes this is influenced by my current work
with eclipse rcp apps :) But their system is a whole lot more
complicated and I don't think we need that much complication.

-- 
You will pioneer the first Martian colony.