kdirlister and friends
brade at kde.org
Mon May 15 08:42:44 BST 2006
On Friday 12 May 2006 14:51, David Faure wrote:
> > 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 strongly disagree, for the same reasons David posted already. You can write
a new model, yes, but leave KDirLister working. Eventually, I will finish
porting it to Qt 4, but right now I lack the time :(
> 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.
Nope, I wouldn't know why anyone wants to use KDirListerCache directly.
Actually, that is not quite possible anyway, one reason being that it's a
> 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 working.
Yes, I couldn't agree more :-)
Michael Brade; KDE Developer, Student of Computer Science
|-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
KDE 4: Beyond Your Expectations
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel