Where to populate Version Control entry

Manuel Breugelmans mbr.nxi at gmail.com
Sun Aug 17 11:07:51 UTC 2008


On Saturday 16 August 2008 22:13:20 Andreas Pakulat wrote:
> Hi,
>
> I wanted to move the code that populates the "Version Control" context
> menu from the individual vcs plugins into a more central place.
> Unfortunately I couldn't quite figure out the apropriate place for it.
>
> My problem is mostly that in shell/ there's only plugin controller who
> can contribute to the context menus, but I don't want the VCS-code
> there.
>
> So I'm looking for ideas how to do this in a clean way, ideally
> something inside the vcs library would do this, but that would need
> either the vcs lib linking to shell or a public signal in the
> interfaces. I don't really like either of the options, but has anybody
> got a better idea?
>

Personally I would still populate in each plugin and instead delegate it to a 
common VcsContextGroup class, activated in the plugin's contextMenuExtension 
member.

like so:
void populate(KDevelop::ContextMenuExtension& menu, KDevelop::Context* 
context);

As the prime actor here is a context action it makes a strong candidate for a 
class as well.  Actually I'm already doing something like this for the code 
generation context actions.

cfr:
kdevelop/languages/cpp/languagesupport.cpp:126
kdevelop/languages/cpp/veritas/stubcontextaction.h
kdevelop/languages/cpp/veritas/uutcontextaction.h

> The reason to still have the VC-Menu populated in a central place
> instead of by the plugins individually is to make sure that any
> VCS-plugin provides some common base functionality with common widgets
> so users don't need to learn a completely different UI everytime they
> have to switch the VC-System.

Doing it like this should make sure the common operations are equal and still 
allow vcs'es to have specific actions. Sure there will be a tiny bit of 
duplication in all the plugins' contextMenuExtension members ... but IMHO that 
is by far the lesser evil when compared to unnecessary complication.


Manuel




More information about the KDevelop-devel mailing list