KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

Frank Reininghaus frank78ac at googlemail.com
Thu Jan 10 17:41:04 UTC 2013


Hi,

2013/1/10 Aaron J. Seigo:
> in the case of dolphin, i can imagine a goal that could lead to over-
> calculating: wanting even spacing between all icons, which in turn means
> knowing how much space each and every icon will require (thumbnail? how much
> text? etc.)

The number of text lines required for each file name is indeed
calculated in advance in order to get the 'maximum scroll offset' for
the view, i.e., the total height of the view containing all items.
This is used to set up the 'scroll bar value' <-> 'view offset'
mapping. One could possibly avoid that by assuming that all
non-visible items only use one line for the name, and only update that
value for items which are inside (or close to) the visible area. But
before considering such a thing, one would need to check if that is
really a significant bottleneck. Quite a bit of code would need to be
changed, and I can imagine that it's not completely trivial to get
this right.

> 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.
Moreover, it seems to me that QML views work best with
QAbstractItemModel subclasses. 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.

Best regards,
Frank


More information about the Kde-frameworks-devel mailing list