[RFC] Context-Menu Handling in KDevelop4

[dukju ahn]

2007/5/8, Andreas Pakulat <apaku at gmx.de>:
> On 07.05.07 14:20:19, dukju ahn wrote:
> > 2007/4/3, Andreas Pakulat <apaku at gmx.de>:
> > > A plugin can't just add actions for a Context, it needs to know the
> > > actual url of the file (in case of a FileContext) to add the right
> > > actions. So we'd end up with a signal again, in which case I don't see
> > > the benefit from using the actionCollection, except that we don't allow
> > > plugins to remove from the menu, only add new actions.
> >
> > Yes. In addition, signal approach allows more dynamic contextmenu fillout.
>
> Its not really about signal or non-signal. Its about not handing the
> KMenu* to the plugins, only allowing them to give a list of actions that
> should be inserted into the menu.
>
> I'm not sure yet how to trigger this, but ideally I'd like to get a
> QList<QAction*> from each plugin and eventually a QString. Then the
> context menu will have an entry with the QString that has as a submenu
> the list of actions.

OK. The KMenu is not handed. Anyway I think the signal approach is
conveninent to fetch QList<QAction*>

>From each plugin/component who wants to launch context menu,
they can invoke some ICore::contextMenu( QList<QAction*>&, Context ).
This method emit signals with QList<>&, Context, and other plugins can
fillout proper actions.

I have question -- if the plugins provide just QString, how does the actions
can be excuted? For example, ProjectManager fetched a string "commit".
Then how ProjectManager can connect it to IBasicVC::commit() ?
I guess providing QAction is reasonable.