kdirlister and friends
faure at kde.org
Fri May 12 13:51:47 BST 2006
On Wednesday 10 May 2006 06:17, Jens Herden wrote:
> is anyone already working on or thinking about kdirlister and friends for
I thought Hamish Rodda had started, but he hasn't answered either of the two posts with
a similar question so I'm not sure anymore ;)
> I think kdelibs should provide a model (KDirModel) for access of filesystems,
> smilar to QDirModel. This model should provide the following features:
> - it supports trees
> - every modelindex gets a pointer to structure with a KFileItem
> and a vector of KFileItems for the entries in the folder
> - you can insert any KURL at any position of the model
> (usefull for in-tree display of archives)
> - the model should use KDirListerCache or a similar class
> (KDirListerCache uses Q3 stuff in the moment)
> - the whole filter and sorting would happen with the help of another class.
> Either in a proxy model or with a KFileFilter, not sure yet.
> My current idea is to move KDirLister to K3DirLister because I think the model
> would do more or less the same. And implementing the model on top of the
> KDirLister seems to be not very efficient.
I don't see why. The model would of course only return the data that's there
at a given moment (keep in mind that kdirlister is asynchronous),
but if the model gets the data from KDirListerCache (which is the one that
owns the kfileitem pointers), that sounds fine to me.
> What would we get from this?
> A good foundation for our views on filesystems. Using this model would make it
> easy to implement different views on the same data. Creating delegates allows
> us to fine tune the displayed data without dealing with the views at all.
> This model could be used for all our filesystem dialogs, Konqueror,
> KFilesTree replacements and many more things I can not imagine yet.
But the best design seems to me laying out the model on top of KDirLister/KDirListerCache.
Something like: I create a kdirlister, ask it to list a given url, and when it's done I create
a model around the dirlister, which then provides the standard interface for displaying
those fileitems that the dirlister holds, into views.
This keeps things cleanly separated between the model (which only works with the
available data) and the dirlister (which lists urls to get that data), allowing to keep
using the dirlister without the model on top of it, in cases where it makes sense
(e.g. when not displaying the results into views ;) - and this also keeps existing 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).
More information about the kde-core-devel