KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Mark]

On Tue, Jan 15, 2013 at 11:25 PM, David Faure <faure at kde.org> wrote:
> On Tuesday 15 January 2013 17:14:52 Mark wrote:
>> We're talking about application level now. In other terms: off topic
>> ;)
>
> Not completely.
> It's good to decide on an overall direction for a given issue, before
> determining which layer should do what.
>
> If we decide that it's ok to compute things incrementally, or to sort only
> when all the data is in, because the application will hide the view until the
> right time, then we know it won't create trouble, so it's a good solution
> overall. Otherwise another solution must be found in the model to prevent
> "things jumping around visually".

Good point :)

I'd say the "programmatic" default is to show data asap even if that
means jumping views.
But perhaps there should be a flag function in KDirModel to change
that behavior. For example the following:

--Enum values
/** Incrementing updates will update the model as soon as data
arrives. This might case the view to jump when new data fed in the
model */
- UpdateFlags::IncrementingUpdates

/** Full updates will only update the actual model data once the
"finished" signal is received from the internal KDirLister. The view
will only change when all data is in */
- UpdateFlags::FullUpdates

Then a KDirModel function for it like so:
KDirModel::flags(UpdateFlags flags);

I think that is reasonable, right? Doing this will give the
application full control whether to use batching
(UpdateFlags::IncrementingUpdates) or nor (UpdateFlags::FullUpdates).
The current behavior is actually batching, but batching _was_ done
very poorly and using application don't really seem to make use of it
anyway - as in the listen for the finished signal thus rendering
batching useless.