[RFC] Context-Menu Handling in KDevelop4

[Matt Rogers]

On May 9, 2007, at 10:04 AM, dukju ahn wrote:

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

it doesn't retrieve already created collections. I left the creation  
of collections abstract explicitly. the thing that iterates over the  
plugins just calls a function defined in an interface.

> 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's slightly less elegant? Because it doesn't provide a  
consistent API for plugin developers to use? Because I didn't write  
it? (ok, so that last one doesn't matter so much. I've had a bad day,  
i deserve to have a little fun)
--
Matt