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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel