KDE/kdebase/apps/dolphin/src

[Peter Penz]

On Saturday, 1. August 2009 03:50:57 Aaron J. Seigo wrote:
> this really, really looks like the kind of thing that would benefit from
> usage of kdevplatform. there's really no point, in my mind, of rewriting
> vcs code over and over again in every app that would benefit from it.
>
> there seem to be technical obstacles to that, however.

I agree that this should be not part of an application and rewritten again if 
there is a quite similar code there already. The code below is just a proof of 
concept an my plan was to provide a base-API in kdebase/lib/konq and to move 
the plugin into implementations into kdesdk/revisioncontrol (see 
http://lists.kde.org/?l=kfm-devel&m=124855492527006&w=2 for details).

I was not aware about kdevplatform/plugins/filemanager-stuff... :-/

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/revisioncontrolobserver.h?view=markup

The only dependency it has to Dolphin is the DolphinModel. In comparison to 
KDirModel DolphinModel adds the revision control information as column. When 
moving this small addition from DolphinModel into kdelibs and also moving 
KRevisionControlObserver to kdelibs, it would be possible for each 
QAbstractItemView to integrate a revision control plugin this way:

QAbstractItemView * view = ...;
new KRevisionControlObserver(view);

and the revision state of each file will be indicated by an emblem. The 
context menu actions also can be retrieved very easily by the offered 
KRevisionControlObserver interface.

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

I had a short look into kdevplatform/plugins/filemanager-stuff and I guess 
this should be possible without much headaches.

Thanks!
Peter


>
> in Plasma, we've run into the issue that the kdevplatform rev control code
> is a bit too tightly integrated into the rest of the whole kdevplatform. we
> have no problems depending on kdevplatform for our needs (Plasmate) but we
> really want just the revision control part of the platform, not everything
> else that comes with it.
>
> for Dolphin, i could imagine that the plugins could live just about
> anywhere, so again the dependency issue shouldn't be huge, but the "whole
> platform" issue comes up again here.
>
> to the KDevelop people: what is the best way to take advantage of the vcs
> code in kdevplatform without implementing a full "KDevplatform" app?
>
> On Thursday 30 July 2009, Peter Penz wrote:
> > SVN commit 1004416 by ppenz:
> >
> > 'Prepare
> >
> >  M  +3 -4      revisioncontrolplugin.cpp
> >
> >
> > --- trunk/KDE/kdebase/apps/dolphin/src/revisioncontrolplugin.cpp
> > #1004415:1004416 @@ -338,14 +338,13 @@
> >      connect(process, SIGNAL(error(QProcess::ProcessError)),
> >              this, SLOT(slotOperationError()));
> >
> > -    QStringList arguments;
> > -    arguments << m_command;
> > +    const QString program = "svn " + m_command + ' ';
> >      if (!m_contextDir.isEmpty()) {
> > -        process->start("svn", arguments <<
> > KShell::quoteArg(m_contextDir)); +        process->start(program +
> > KShell::quoteArg(m_contextDir)); m_contextDir.clear();
> >      } else {
> >          const KFileItem item = m_contextItems.takeLast();
> > -        process->start("svn", arguments <<
> > KShell::quoteArg(item.localPath())); +        process->start(program +
> > KShell::quoteArg(item.localPath())); // the remaining items of
> > m_contextItems will be executed // after the process has finished (see
> > slotOperationFinished()) }