Where to populate Version Control entry

[Andreas Pakulat]

On 18.08.08 09:35:42, Manuel Breugelmans wrote:
> On Sunday 17 August 2008 20:02:56 Andreas Pakulat wrote:
> > On 17.08.08 13:07:51, Manuel Breugelmans wrote:
> > > On Saturday 16 August 2008 22:13:20 Andreas Pakulat wrote:
> > > > 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
> >
> > I've looked through your code and I think what your idea is. The problem
> > is that this class would still populate the group multiple times as
> > multiple vcs plugins might say they can handle a given context item. 
> 
> Aha, you don't only want to move the code to a common place but also populate  
> _once_ for the different plugins,  in some kind of singleton. Yes then that 
> solution above won't cut it. Are you triple sure that no context will ever 
> need actions for multiple vcs though? I'm not saying it will, just asking.

I'm sure there are cases where two VCS systems can handle a given
context. For example some time ago I imported a project that was hosted
with CVS into an svn repository and kept the CVS-stuff alive to do
remote-updates every now and then (I needed to make some local
modifications to the code and wanted to keep them in a repository). So
thats a case where both CVS and SVN would want to have actions, however
having a single submenu labelled "Version Control" and two commit items
in it doesn't work. There can be only one dedicated VCS for a given
project in KDevelop. The vcs-plugins however are free to supply their
own extension submenu, for example "CVS", "Subversion", "Git". They
already do that right now.

Anyway, the solution with a new plugin and some discipline regarding
what/where the other VCS plugins plug their actions into should work
quite well.

Andreas

-- 
Don't read everything you believe.