[RFC] Workingstyle of different VCS systems

[Matthew Woehlke]

Andras Mantia wrote:
> On Friday 13 April 2007, Matthew Woehlke wrote:
>> I think we are talking about the same thing. If the interface with
>> diff() is implemented, the objective is for KDevelop to add that to
>> the context menu, right? So in this instance the plug-in says "I
>> implement diff()", and KDevelop asks if it does and then adds
>> "Diff...", yes? IIUC things that don't have an interface are added
>> explicitly by the plugin.
> 
> I think you missunderstood how the KDevelop platform works. Here it is 
> not "KDevelop" who asks the plugins what do they support and add menus 
> based on them, but the plugins are the ones who fill up the menus!

This means every plugin has to ask KDevelop to fill in the menu. 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.

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

-- 
Matthew
Current geek index: 62%