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

Peter Penz peter.penz at gmx.at
Wed Aug 5 06:49:59 UTC 2009


Hi Aaron,

Are there any news on the plasma-front regarding the VCS-related requirements?

Andreas and I would be interested especially into the following two things (see e-mail below for more details):

Andreas: "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?"

Me: "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..."

Thanks :-)
Peter

-------- Original-Nachricht --------
> Datum: Sun, 2 Aug 2009 17:43:48 +0200
> Von: Peter Penz <peter.penz at gmx.at>
> An: Andreas Pakulat <apaku at gmx.de>
> CC: "KDevelop-Devel" <kdevelop-devel at kdevelop.org>, "Aaron J. Seigo" <aseigo at kde.org>, Faure David <faure at kde.org>
> Betreff: Re: Sharing VCS-related code across KDE apps [Was: Fwd: Re: KDE/kdebase/apps/dolphin/src]

> 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




More information about the KDevelop-devel mailing list