[RFC] Workingstyle of different VCS systems

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Apr 13 19:22:55 UTC 2007


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?

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.

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

-- 
Matthew
Current geek index: 62%





More information about the KDevelop-devel mailing list