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

[Peter Penz]

On Sunday, 2. August 2009 13:00:15 Andreas Pakulat wrote:
[...]
> > 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.

I was not aware about this, but I think this can be solved (see below).

[...]
> > 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/revisioncontrol
> >plugin.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

Yes...

> 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.
 
I agree. I had a more detailed look in the meantime into kdevplatform/vcs and 
kdevplatform/plugins and it's great how much functionality is offered already. 

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

I think it would be possible to abstract KRevisionControlObserver in a way 
that it is not bound to KDirModel/KFileItemDelegate.

But this raises the question whether KRevisionControlObserver and 
KRevisionControlPlugin should be moved to kdelibs at all. In my initial mail 
at kfm-devel (http://lists.kde.org/?l=kfm-devel&m=124855492527006&w=2) I 
proposed to move them into kdebase/lib/konq.

kdevplatform may use things from kdebase/lib/konq, but e. g. Dolphin may not 
rely in having an installed kdevplatform. But let's wait for Aaron's input...

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

For me it would also be interesting whether you require emblems for 
QAbstractItemView or whether we must do an abstraction like in 
KFilePreviewGenerator which allows to have emblems on e. g. the folderview 
applet, where we used the (internal) KAbstractViewAdapter class...

Peter

> 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