On Tuesday 08 January 2013 15:52:23 Aurélien Gâteau wrote: > Le lundi 31 décembre 2012 11:43:47 David Faure a écrit : > [snip] > > > If you want to think "bigger redesign", one could consider adding the > > necessary API to KDirModel so that direct usage of KDirLister isn't > > necessary anymore, i.e. encapsulating it completely. Then looking at > > whether all the app code can be ported away from KDirLister, to use either > > KDirModel or KIO::listDir (when no storage is required, just a one-time > > listing). > > > > A quick look at lxr.kde.org (for "KDirLister") seems to indicate that this > > should be possible. > > Most cases are using a KDirModel already, and just use KDirLister to call > > openUrl or to enable "directories only" mode. > > On the other hand, > > http://lxr.kde.org/source/kde/kdeedu/kstars/kstars/ekos/capture.cpp > > should use KIO::listDir directly, I think. > > http://lxr.kde.org/source/kde/kdegraphics/gwenview/importer/documentdirfin > > de r.cpp too, AFAICS. (Aurélien: storing the items isn't needed, in that > > code, right?) > > Not sure what storing you are referring to: this code does not store any > item, does it?
KDirLister does. The whole point of KDirLister is to list a directory *and* get updates later on when something changes. And if you list the same directory again later, you get cached items first and then an update for anything that changed meanwhile. So it's really made for views, rather than for non-gui application logic. If you just want a one-time listing of a directory, no updates and no caching, KIO::listDir does that. > Anyway this whole class is not needed anymore, I should just > remove it. Ah well, that's simpler then :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
