[RFC] Context-Menu Handling in KDevelop4

[dukju ahn]

2007/5/9, Matt Rogers <mattr at kde.org>:

> > Yes. In addition, signal approach allows more dynamic contextmenu
> > fillout.
> > For example, contextMenu( ProjectFileContext*, KMenu* ) is emitted.
> > Whenever emitted, each VCS plugins (for example) can test whether
> > this file is under version control. So if not version controlled,
> > no context
> > menu will be created.
> >

> I still prefer the use of the actionCollection to hold plugin
> actions, because we're not dealing with a menu, we're dealing with a
> set of actions that could be represents in many ways for a GUI. We'd
> still have a context, of course, because some actions just won't
> apply in some cases. So, now for some very high level psuedo-code:
>
> for all the currently loaded plugins
>    call actionCollection( const Context& context ) to retrieve an
> action collection
>    merge just returned action collection into main action collection
> for loop done
>
> create menu based on main action collection
> show menu

Retrieving ActionCollection is good. But what I wanted to discuss was getting
actionCollection dynamically.

For example, suppose that context menu was requested for
NON-VCS controlled files. Then, VCS plugin don't want to add his ActionColls
to this context menu. Simillary, C++ source navigator or CTags plugin
don't want to
show "jump to void" or "jump to int" etc.
So whenever contextmenu was requested, each plugins want to decide whether he
will insert its submenu(subactions) or not.
It's RUNTIME, NOT PLUGIN CREATION TIME.

Now, if we use Matt's psuedo-code above, which just retrieves already
created collections,
can we do such tests above? I ask because, AFAIK, actionCollection is created
at plugin creation time.

Also, rather than iterating method, why don't we just use signal-slot technique?
It's more simple and lesser code while doing the same thing.