[RFC] Context-Menu Handling in KDevelop4

[Andreas Pakulat]

On 10.05.07 00:04:34, dukju ahn wrote:
> 2007/5/9, Matt Rogers <mattr at kde.org>:
> > 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.

Thats what we're doing here.

> So whenever contextmenu was requested, each plugins want to decide whether he
> will insert its submenu(subactions) or not.

Right.

> It's RUNTIME, NOT PLUGIN CREATION TIME.

We were never talking about 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.

No it doesn't retrieve created collections. It doesn't use the standard
actionColllection of the plugin. That action collection is used to add
items to the menu and toolbars, this is not about the context menu.

> 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.

Because it doesn't make a difference and we have control over which
plugins we ask. For example certain plugins may be disabled for a given
project, so when creating a context menu the plugincontroller only asks
the plugins that really are available for their action-list (note how I
avoid the name actionCollection, because what we retrieve is really just
a list of QActions*).

Also it doesn't gain anything, except hard-to-follow code because the
signal signature is:

getContextAction( KDevelop::Context*, QString&, QList<QAction*>&)

This is the only way to let the plugins fill the string and list and to
me this seems awkward because signal/slots is not about transferring
data back and forth its about telling everybody who wants to know that
something happened.

Andreas

-- 
You'll feel much better once you've given up hope.