Adding dependency on kdebase to kdegraphics

[David Faure]

On Saturday 21 July 2007, Aurélien Gâteau wrote:
> Andreas Hartmetz wrote:
> 
> > On Saturday 21 July 2007 00:43:28 Aurélien Gâteau wrote:
> >> Hello
> >>
> >> I am in the process of adding basic file operation support to Gwenview.
> >> To avoid code duplication, I would like to use libkonq, but it would add
> >> a dependency on kdebase to kdegraphics. Is it a problem? or is there a
> >> better way?
> >>
> >> Aurélien
> > 
> > File operations? Excuse my ignorance, but that rather sounds like we have
> > a problem in kdelibs if you need lib*konq* for file operations. Obviously
> > there are QFile and everything in libkio which are not enough for whatever
> > reason. What exactly is it that you need? I guess it's rather GUI
> > related... Could it be a case for kdelibs/kdeui ?
> 
> libkonq is a bit higher level, have a look at KonqOperations: it has nice
> static methods like to copy, rename, paste from clipboard, ask delete
> confirmations. I could reimplement it (that's what I did in Gwenview 1.4)
> but I think it's not the smartest thing to do.

Yes KonqOperations seems quite popular, many apps are using it or want to use it
(dolphin, konqueror, krusader?, gwenview, fsview, and kicker in the past). It makes no sense at all
to move all of libkonq to kdelibs (there's quite some old cruft in there), but
a KIO::FileOperations might be useful. But not even with all of its current code.

In fact, why not use KIO::copy() instead of KonqOperations::copy()?
With a call to job->ui()->setWindow(this) and a call to job->setAutoErrorHandlingEnabled(true)
you get the same behavior as KonqOperations::copy() AFAICS. Ah, except for
the undo support, but is this needed by e.g. gwenview? Otherwise it's really a 3-liner
using KIO.
For instance I'm really wondering why kdepasswd/kcm/chfacedlg.cpp uses KonqOperations::copy :)

I think the real value of KonqOperations is:
1) the support for undo. This is the main reason for the wrapping of the KIO api;
in konq+dolphin we don't just KIO::copy/move/rename, we also record undo for it,
hence the wrapping of the KIO api in KonqOperations. So the questions: which apps
(in svn) other than konq+dolphin need support for undoing file management operations?
2) delete confirmations -- surely we can come up with a nice API for this in kio...
3) paste, which is mostly KIO::pasteClipboard with added support for "cut"
(but does gwenview use "cut"?)
4) handling of dropped urls (including popup and modifiers) -- but you didn't mention it,
and IIRC dolphin has its own more recent code for this. Still, we could consider some KIO
API for this, if needed.
5) advanced trash support (not just "trash this item" like KIO has), but emptying and restoring
is quite filemanager-only. I certainly wouldn't want gwenview to empty konqueror's trash :)

I can see from your description that the added value of KonqOperations is also that
all operations are in a single place instead of being dispatched over a number of KIO
classes - e.g. did you know about KIO::pasteClipboard? But this could solved with improved
documentation, if that's the only issue.

Summary: I'm for extending the KIO API with the little bits of missing stuff rather than
moving libkonq or even KonqOperations altogether.
But I can also easily be convinced about moving KonqUndoManager and adding an API
for delete confirmations [which is also needed by KonqUndoManager] in KIO, if there's
enough interest about that, and not too many objections [e.g. relative to new kdelibs code...].

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).