KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Aaron J. Seigo]

On Thursday, January 10, 2013 18:41:04 Frank Reininghaus wrote:
> before considering such a thing, one would need to check if that is
> really a significant bottleneck. 

if it means having to calculate by iterating over every single item in a 
listing, then it will eventually become a bottleneck. the goal should be to 
only list and process items that are actually being viewed. temporary 
innacuracies in the scroll bar are far better than a slow view.

> Quite a bit of code would need to be
> changed, and I can imagine that it's not completely trivial to get
> this right.

it probably doesn't need to be perfect. it only needs to be "good enough". if 
the scroll bar updates a few pixels here and there while dragging, i'll bet 
that's better in terms of real world usage experience than any lag in the 
view.
 
> > if that is the case currently, i would suggest dropping this goal
> > and only change the spacing dimension when new icons are shown that
> > require
> > it. (again, easy enough with QML.)
> 
> Well, the hard part is probably to port Dolphin's views to QML in the
> first place ;-) I must admit that my QML knowledge is rather limited,
> but AFAIK, it does not provide any kind of tree view out of the box.

no tree views, no. at least not until desktop components come in 5.1.

icon and list views are trivial. tree views can be 'faked', but yes, that will 
take a bit of effort. far less effort than doing it in c++ though :)

> Moreover, it seems to me that QML views work best with
> QAbstractItemModel subclasses. 

yes.

> However, one of the main goals Peter
> had when rewriting the view engine was to get rid of QModelIndex,
> SortFilterProxyModels and things like these. And I really have the
> feeling that using plain ints to index items and not needing things
> like mapToSource() in every other function really does make things
> easier.

with QML, you can get rid of C++ SortFilterProxyModels and do this in QML 
itself. it uses proper models in the background (so it's fast) and it becomes 
insanely easy to get sorting and filtering.

with QML, QModelIndex will only appear in the actual model itself (KDirModel, 
e.g.; or in the case of Mark's "porpoise" DirModel which adds thumbnailing on 
top of KDirModel) so you only care about this in the one model.

the UI, and even the sorting and filtering bits, no longer see any of that 
complexity. this is perhaps one of the best bits of QML when it comes to data 
models.

the downside to QML and models is that it doesn't understand models that are 
trees out of the box. it basically wants big flat lists. you can work around 
this with fairly minimal effort, though.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130110/44c47222/attachment-0001.sig>