Konqueror 4

[Kevin Ottens]

Hi all,

Le Lundi 30 Octobre 2006 11:53, David Faure a écrit :
> 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.

At least we would already have a name... a cuter one than kfm. :-)

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

Well, I somehow doubt this needs to be shared. As you already pointed I doubt 
people use more than one level of splitting. It becomes quickly unmanageable 
to a user IMHO.

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

Hmm, I'm not exactly sure what you mean here. At least dnd and previews 
support in model classes like KDirModel and KFileItem looks strange to me (I 
could probably live with the preview there though). Could you elaborate a 
bit?

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

As your evil clone, I agree with this approach. :-)

More seriously, it looks like the best way to go. Having building blocks 
shared (through libkonq I guess) and applications using them. Such a "file 
management toolkit" is interesting by itself.

Now that I think of it, it might even be of interest for the people working on 
krusader... No idea if we have some of them subscribed here.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061030/86227a76/attachment.sig>