Sharing VCS-related code across KDE apps [Was: Fwd: Re: KDE/kdebase/apps/dolphin/src]

[Peter Penz]

Hi Andreas,

On Sunday, 2. August 2009 03:02:55 Andreas Pakulat wrote:
> On 01.08.09 21:15:10, Peter Penz wrote:
[...]
> > I was not aware about kdevplatform/plugins/filemanager-stuff... :-/
>
> Well that stuff really is just a thin wrapper around KDirOperator and
> not so much what this is all about.
>
> > Hmm... The plugin base class for integrating a revision control system
> > into any kind of QAbstractItemView is quite trivial and currently part of
> > Dolphin:
> >
> > http://websvn.kde.org/trunk/KDE/kdebase/apps/dolphin/src/revisioncontrolo
> >bserver.h?view=markup
>
> Thats nice already, the emblem-stuff is something which I haven't yet
> looked at integrating (not only for the filemanager, but also for
> project views and the editor-tabs in kdevelop).

Yes, I think it would be nice for KDevelop to show the revision states in the 
project view as emblems. It's "good" that this is not available in 
kdevplatform yet, as it means we don't have a functionality overlap here and 
no NIH-syndrom on Dolphin side :-)

This is also the only main purpose of Dolphin's revision control observer: 
Assure that the emblems of a QAbstractItemViews with a KDirModel are updated 
when a file or the revision state changes.

To implement this functionality, only a quite small interface for plugins is 
required 
(http://websvn.kde.org/trunk/KDE/kdebase/apps/dolphin/src/revisioncontrolplugin.h?view=markup 
- please ignore the SubversionPlugin test class at the bottom).

>
> > Would it be possible that someone from the kdevelop team might have a
> > short look into
> > http://lists.kde.org/?l=kfm-devel&m=124855492527006&w=2 (description of
> > plugin interface) to check whether it is possible to move the
> > vcs-specific codebases into separate plugins (like Andreas mentions in
> > the other mail)?
>
> Unfortunately thats not enough for us. The really interesting stuff
> regarding VCS in KDevelop/KDevPlatform is in
>
> kdevplatform/vcs/*
>
> and related plugins are in
>
> kevplatform/plugins/subversion
> kevplatform/plugins/git
> kevplatform/plugins/mercurial
>
> As KDevelop wants other plugins to have full access to the VCS API we
> need a bit more than the API of your current revisioncontrol plugin.
> However I'm pretty sure that the actual implementation of at least the
> subversion plugin can easily be moved out - based on the interfaces and
> classes in the kdevplatform/vcs library.

I need to check those plugins in more detail during next week, but the plugin 
interface from Dolphin 
(http://websvn.kde.org/trunk/KDE/kdebase/apps/dolphin/src/revisioncontrolplugin.h?view=markup) 
should not and cannot compete with the functionality offered in kdevplatform.

Above I mentioned that the main purpose of the Dolphin interface is to take 
care on the emblems. As second purpose the interface allows to get some 
context menu actions to access basic revision control commands - and this is 
where Aaron is completely right: The functionality behind those actions should 
not be copied again if this is already available in kdevplatform.

So if we agree that KDevelop & Co want to have a treeview with emblems and to 
eliminate the code duplication in Dolphin's SubversionPlugin, I'd suggest the 
following:

1. I move the Dolphin classes "KRevisionControlPlugin" and 
"KRevisionControlObserver" from Dolphin into kdelibs (for sure I'd ask for the 
OK on kde-core-devel).

2. This would require to extend KDirModel by a Revision-column (need to 
discuss with David Faure, code in Dolphin is already there) and 
KFileItemDelegate by the emblem-code (quite trivial - need to discuss with 
Fredrik Höglund).

3. I'd move the SubversionPlugin test implementation from Dolphin into 
kevplatform/plugins/subversion (-> KDevelop & Co. would gain to have emblems 
for the project view).

4. Cleanup the codebase for (Dolphin-)SubversionPlugin to share the code with 
the kdevplatform-plugin-code for subversion. As mentioned above I did not 
check the implementation of kdevplatform in detail yet, but my guess is that 
the (Dolphin-)SubversionPlugin requires only a subset of the offered 
functionality.

So this would mean that applications like KDevelop or Plasmoids would gain 
having revision state informations for item views and access to basic revision 
control commands just by plugging KRevisionControlObserver to an item view. 
The code for the commands would be shared with the existing implemented 
functionality in kdevplatform.

Would this be OK? If "yes", I'd prepare steps 1 and 2 for Monday the 9th of 
August and would make a review-request for kdelibs a few days before.

For step 3 and especially 4 I guess I need a little bit more time, but there 
is no need to hurry IMO ;-)

What do you think?

Best regards,
Peter

>
> There might not be a need to extract all the interfaces, I guess for
> most apps its enough to have the IBasicVC interface which basically
> provides access to local working copies/clones of a repository. So the
> shared interface would be something based on IBasicVC, but each plugin
> would also expose a plugin-specific public API such that
> KDevelop/KDevPlatform can implement its complete VCS-API based on that.
>
> Thoughts, Opinions?
>
> Andreas