[RFC] Context-Menu Handling in KDevelop4

[Matt Rogers]

On May 7, 2007, at 1:20 PM, dukju ahn wrote:

> 2007/4/3, Andreas Pakulat <apaku at gmx.de>:
>> On 03.04.07 16:56:57, Matt Rogers wrote:
>>> On Apr 3, 2007, at 2:15 PM, Andreas Pakulat wrote:
>>>> so I finally came around to ask Adam what he meant with the  
>>>> comment on
>>>> KDevelop::MainWindow::fillContextMenu().
>>>>
>>>> His response was:
>>>> ,----
>>>> | Well, kdevelop has this notion of global context's such as 'file
>>>> context'
>>>> |
>>>> | If a plugin wished to add an action to the context menu shown
>>>> whenever a file
>>>> | is selected it would just call:
>>>> |
>>>> |         'KActionCollection *ICore::actionCollection
>>>> (ICore::FileContext)'
>>>> |
>>>> | or something and retrieve the action collection for that context
>>>> as denoted by
>>>> | some enum.  The plugin could then plug it's actions into it or
>>>> something.
>>>> |
>>>> | Hadn't really thought it out.
>>>> `----
>>>
>>> I prefer the actionCollection way as well. Do you have a proposed
>>> patch for how it would work when writing code to use it?
>>
>> No, I didn't even think about it too long. However having done so  
>> now I
>> see a problem here:
>>
>> 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.
> 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.
>
> If using actionCollection, I can't imaging how such dynamic menu  
> creation
> is possible.
>
> So I support the KDev3 way.
>
> -# Create a popup menu in context menu event handler:
> @code KPopupMenu menu(this); @endcode
> -# Create a context:
>  @code MyContext context(param). @endcode
> -# Fill a context menu:
> @code core()->fillContextMenu(&menu, &context); @endcode
>  ==> signal is emitted here.
> -# Show the popup menu:
>  @code menu.exec(event->globalPos()); @endcode
>
> Any objection? If no objection, I'll be the one who will implement
> this upcomming weekend.


Yes, objection.

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


Is this approach feasible? What approach does using a signal gain us  
over this approach?
--
Matt