KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Jon Severinsson]

On Wednesday, January 9, 2013 16:42:25 Mark wrote:
> KDirLister ends up high in the stack because it parses a massive QByteArray
> that comes from kio_file. I wasn't actually talking about the stat call but
> more about the massive data (as a result of that stat call) that gets send
> back.

On Wed, Jan 9, 2013 at 2:51 PM, David Faure <faure at kde.org> wrote:
> You realize that "fetching the additional info" means an async kio job, in
> the general case (non local files), right?

On Wednesday, January 9, 2013 16:42:25 Mark wrote:
> Ah crap, didn't thought about that one.. How can that be resolved?

On Wed, Jan 9, 2013 at 2:51 PM, David Faure <faure at kde.org> wrote:
> Did you check the speed difference between details==0 and details==2?
> For local files it's "just" one stat() call per file [...]. And for other
> protocols there's no difference, even (with FTP you have to list the
> directory, which gives you full details anyway), so the two-stage approach
> will only make it slower.

On Wednesday, January 9, 2013 16:42:25 Mark wrote:
> Show data as early as possible even if it's incomplete. Defer the
> complete data set to:
> 1. when it actually needs to be shown (thus a lot less data)
> 2. only fetch the extra data when it's really needed to display or
> calculate something

On Wednesday, January 9, 2013 17:29:31 Aaron J. Seigo wrote:
> imho, one place that dolphin currently fails in going too far in this
> direction is that folders do not get a folder icon until thumbnails start
> dribbling in. using the generic mimetype icon for a folder for even a split
> second not only looks bad, it impacts the usability of the listing as the
> folder/file division is significant in these contexts.
> 
> so while i agree with your theory, there is a lower limit to the amount of
> data needed to be minimally useful.

This is just some thoughts from top of my head, I haven't looked at the 
relevant code so I might be wrong, but shouldn't it be possible to do lazy 
initialization, but still "filling in" any data provided "for free" by the 
directory listing.

That way there will be no "second stage" for protocols like FTP where the 
directory lising gives all available info, and at least the type of file 
(directory, fifo, socket, device, symlink or regular file) will be available 
from start on most local filesystems.

Sure, for FTP etc. you will still get the big blob of data to parse, but that 
should be negligible compared to the time it takes to fetch the info (and 
anyone expecting a remote directory listing of 100'000+ files to be fast are 
obviously deranged), and on some file systems you'll still get the generic 
mimetype icon for directories for a while (though extX will work by default 
(can be disabled by mke2fs / tune2fs), and btrfs, vfat, ntfs3g, etc. will 
always work), but it should be possible to make this solution work better than 
the earlier proposals.

Just *my* € 0.02

/ Jon Severinsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130109/3f13138b/attachment.sig>