KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Mark]

On Tue, Jan 8, 2013 at 5:41 PM, David Faure <faure at kde.org> wrote:
> 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, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>

A little more in depth questions for KDirLister and KFileItem. In my
profiling KFileItem ends up high due to various reasons, but
KDirLister is also a bit of a heavy resource hog due to it's default
behavior of fetching all file information (thus at least 1 stat call
per file) which severely slows down the dir listing process for large
folders.

My idea is as follows here. By default fetch as little information as
possible. So make KDirLister fetch the folder content using "details =
0" by default. Perhaps with an additional KDirLister function (or
flag) to change it's behavior to fetch all info (like it works now).
The magic should happen in KFileItem. Right now that class isn't lazy
loaded at all thus you get as many KFileItem instances as you have
entries in the folder your listing. What i want to do here is make it
lazy loading. When the class constructs it should have the immediate
availability of the current UDSEntry without making anything heavy.
The model can then use this class just fine. When a KFileItem is
constructed it should (in the background) fetch the file to get all
the details. When that's done it should notify the model of the data
change which in turn makes the model update it's data.

Using this approach the model can show data a lot faster (it doesn't
have to wait for the file details anymore) and will automatically
update it's entry when KFileITem tells it to do so.The net result for
the user should be a much faster (visually) file browsing experience
which should be a lot less taxing on the CPU and memory.

Best of all, this can all be done internally in KDirLister and
KFileItem without changing any public API. ABI will change though ;)
Does this sound like a good idea?