Extensible context menus

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday, 8. March 2008, Andreas Pakulat wrote:
> 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?

The classic Drupal influenced mindset's approach: weights.

class ContextMenuContribution
{
public:
...
   virtual int subMenuWeight() { return 0; }
...
}

Then sort all menus by weight (for example, -20 as first
sub-menu, 0 as second 
one, 17 as third one) and you've got a persistent order -
assuming that 
plugins try to keep their weights reasonable in comparison
to other modules.

If a ContextMenuContribution is supposed to be used in
multiple contexts, that 
context (QString uniqueContextIdentifier?) would probably
need to be passed 
as parameter for the weight method.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 10.03.08 13:19:15, Jakob Petsovits wrote:
> On Saturday, 8. March 2008, Andreas Pakulat wrote:
> > 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?
> 
> The classic Drupal influenced mindset's approach:
weights.

Aah, indeed. Why didn't I think of that 

> If a ContextMenuContribution is supposed to be used in
multiple contexts, that 
> context (QString uniqueContextIdentifier?) would
probably need to be passed 
> as parameter for the weight method.

The function that fetches the contributions from the plugins
will still
provide an instance of IContext, so plugins know the context
to which
they shall provide actions and can store the context if
needed for
properly handling action activation.

Andreas

-- 
Today is what happened to yesterday.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel