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

[Andreas Pakulat]

On 02.08.09 09:15:39, Peter Penz wrote:
> 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.

The project view has its own model as it'll show more than just the
files/folders and the items also carry more information. So that won't
work so easily.

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

If course not, I think the idea would be having the complete Svn/Git/XXX
functionality available for all KDE apps, but each app only uses from
that what it needs. So for example dolphin would do something along the
lines of:

IVcs* vcs = someFactory->vcsForUrl( somelocalurl );
VcsStatusInfo = vcs->status( somelocalurl );

And then return that information via the observer. And for the context
menu it would be similar.
 
> 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:

As I said above that won't really work as the project treeview is not
based on KDirModel and additionally we also want emblems in other parts
(like the commit dialog, the tabbar and possibly other places).
 
> 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.

Aaron, can you comment on the needs of plasma? Do you also just need
emblems+context menu with some actions for a local working
copy/repository-clone?

As I said from KDevelop's point of view it would make most sense to move
out the VCS-abstraction layer and the actual plugin-implementations.
Anything else won't be enough and hence we won't be able to benefit from
it.

Andreas

-- 
You could live a better life, if you had a better mind and a better body.