Konqueror 4

[David Faure]

Hi all,

I think I have come to a point where I'd like us to try and make a separate filemanager application,
which we could even name dolphin if Peter agrees, as long as we share as much code as possible
with konqueror the browser, and with the file dialog.

In particular, how about we make a standalone library (well, or set of classes in libkonq)
for the view framework? That is: support for any level of view splitting and for tabs, and 
the related kactions.
This assumes that we actually need nested view splitting in the file manager though,
as opposed to just one splitter i.e. one level of splitting like in dolphin. I'm not sure
this is actually used; I often split, but never more than once.
This also assumes that we need tabs in the filemanager but I read in the openusability 
study about filemanagers that users liked the tabs in konqueror and were missing 
them in Windows. A bit surprising to me given that tabs make DnD of files between
directory views impossible...

In terms of sharing with the file dialog, I mean that kdirmodel and kfileitem can provide
most of those standard features related to file items: tooltips, dnd, previews, delayed
mimetype determination, etc. (This is my next line of action).
Another level of sharing with the file dialog might be sharing views and delegates,
but we'll have to see how that goes (for instance I like the idea of a delegate that
shows some details in the text under the icons in the icon view, but that's not 
something for the file dialog I guess).
OTOH the file management operations (copy/move/delete/move-to-trash with
confirmation and undo/redo support etc.) as implemented by KonqOperations and KonqUndo
in kdebase/libkonq are probably useful for kfiledialog too.

I really don't have strong opinions on how the GUI should be like 
(that's what we have the usability group and our users for), my main goal is to
design all this from a sound technical point of view, which means as much modularity
and code reuse as possible.

I think the best approach at this point would be to
1) continue the work on the "building blocks" for file management (model, views, 
common filemanagement operations etc.)
2) create a kde4-based dolphin based on those building blocks -- which doesn't really
mean a straight kde4 port of the current dolphin codebase, but rather porting the
core of dolphin (and using kde4 stuff for the rest of it (for instance I think that bookmarks
should use kio/bookmarks, with a different xml file than the one used by konqueror,
and that undomanager should use KCommandHistory from kdeui and/or konq_undo, etc.). 
By working on dolphin in kdebase we can make it use more of kdelibs4 to avoid some 
of that duplication of code and efforts.

I'm happy to contribue to both parts of the work, of course.
What do you think about this approach?


Peter (I see you're subscribed), how do you like the idea of "porting/restarting" dolphin
in kdebase svn? See http://developer.kde.org/joining/applysvnaccount.php to get a svn account.

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