[RFC] Workingstyle of different VCS systems

[Andreas Pakulat]

On 13.04.07 12:54:59, Matthew Woehlke wrote:
> 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.

No, KDevelop asks each plugin to add Actions to a actionCollection,
based on a given Context subclass. Such a Context subclass can be
FileContext (just the filename), or EditorContext (with line/col infos.
And then KDevelop will build a Context Menu based on the actions in the
collection. (This is not implemented yet, but thats the plan. Currently
the plugins are asked to add to a QMenu* pointer whatever they want).

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

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

Andreas

-- 
You have a will that can be influenced by all with whom you come in contact.