KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Mark]

On Thu, Jan 10, 2013 at 7:24 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday, January 10, 2013 16:49:15 you wrote:
>> On Thu, Jan 10, 2013 at 3:53 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> > * DirModel::updatePreview calls setData for each preview that it gets
>> > back.
>> > that causes dataChanged to be emitted. again, for each index. this needs
>> > to be batched up and/or DirModel should override data() itself to return
>> > Qt::DecorationRole when it has a preview.
>>
>> Would a 300ms timer be acceptable in user experience? So if there are
>> new thumbnails available, batch them and update the model only once
>> every 300ms. Or is 300ms too much?
>
> probably too much (and probably more than is needed for the rate of file
> listing). but once you have that delay in there it is easy to test it, right?
> 100, 200, 300 .. it will really come down to average listing performance. if
> items come in clumps, then the update might only need to be really small (50ms
> or even less) to drop the # of updates by orders of magnitude.

Guess i just have to experiment there.

>
>> Interesting! My DirModel is coming directly from plasma-mobile [1]
>> which is not doing the threading you describe.
>
> yes, i noticed :) unfortunately for you, that class was thrown together very
> quickly for the limited needs of listing directories on a mobile device. file
> counts tend to be rather low there, and file system browsing is not as core a
> function as it is on the desktop. so for Plasma Active, this was acceptable
> performance. for the desktop .. not even close :)

Well, the class didn't have _that_ much extra stuff on top of
KDirModel and i added even more so mine is quite different at the
moment. Though not threaded.
>
>> Is there another
>> dirmodel fork somewhere that does that? Link please :)
>
> well, what we ought to do is do a threaded version and then put it somewhere
> we can all share it properly :) i'll discuss with Marco what he thinks and
> come back with a proposal.

you make it sound like it's closed source..? no link to some exotic
highly experimental git branch?
>
>> You just verified the need for KDirModel, KDirLister and KFileItem to
>> be optmized for scalibility :-)
>
> yep.
>
>> How much work would it be to let KDirModel run in it's separate
>> thread? I'm guessing the public KDirModel would internally be nothing
>> more then a signal/slot mechanism to a KDirModelPrivate class which is
>> sent to it's own thread? Or would you say that sending KDirModel to
>> it's own thread it too risky and should be done by the developer using
>> KDirModel (like dolphin and my app) rather then internally in the
>> private API?
>
> for scalable models in Plasma Active, we've been putting the threading in the
> model itself exactly as you described (threaded signal/slot communication
> between the public API model and members in its private class) since doing
> this in each application is error prone. once it is done properly in the
> model, it then works everywhere.
>
> so +1 from me for making KDirModel do its business in an encapsulated thread.

I guess that is the way forward then. But i do wonder, if the
KDirModel API stays the same but the internals change completely, is
that KF5 material or can it go in 4.xx as well?
>
> --
> Aaron J. Seigo

(remember to press "reply to all" ^_-)