[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 14:22:55, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 13.04.07 12:54:59, Matthew Woehlke wrote:
> >> At the very least, we need to have a 'fill in menu' for each standard
> >> interface we implement. But I still don't see why KDevelop
> >> couldn't/shouldn't do this for the back-ends.
> > 
> > Because that introduces more code is currently the only thing that comes
> > to my mind. We ask all plugins anyway to add actions to an
> > actioncollection, so why should we treat VCS plugins differently?
> 
> ...because we know that VCS plugins will implement the same actions?

Uhm, no. The actions will be provided by the gui-supplement-lib, all the
plugins have to do is connect the actions to their slots.

> I guess I'd be OK with addStandardVCSActions(theMenu, this), or even 
> addVcsFooInterfaceActions(theMenu, this), but I don't see why we 
> shouldn't provide at least this. If we don't, we're just duplicating 
> code in each plug-in to add the same actions.

Uhm, the plugins have to connect to the slots of the actions. so this
doesn't make sense.

> >>> And this is one of the reasons why there shouldn't be everything in
> >>> the interface. If your vcs plugin has an entry called "Cool" and no
> >>> other vcs plugin supports this "cool" action, the plugin could still
> >>> provide it in the context menu.
> >> I think you're totally missing the point. I *never* said that back-ends 
> >> can't implement non-standard interfaces! In fact, I fully expect that 
> >> will be the case (like svn's cleanup, for example, that doesn't seem to 
> >> match closely to anything in any other VCS). Having KDevelop fill in the 
> >> menu, and having the plug-in fill in the menu are *not* mutually 
> >> exclusive. All I am saying is it would be convenient for KDevelop to do 
> >> the legwork for the standard interfaces so that all the plugin needs to 
> >> do is add anything *extra*, if it needs to.
> > 
> > See above, having KDevelop doing this will introduce more code. Also
> > this will get complicated because for a project file kdevelop first has
> > to find a VCS plugin that feels responsible for that file. If kdevelop
> > just asks all plugins to add actions and gives the project file in the
> > Context then the plugins can decide themselves.
> > 
> > The QAction objects themselves can of course be shared (and thus
> > translations) via the supplement library.
> 
> I'm confused, when I talked about this earlier you didn't want to do 
> this. Are you changing your mind, or are we just mis-communicating?

Huh? I don't think I ever said that, did I?

Andreas

-- 
Your domestic life may be harmonious.