KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

[Aaron J. Seigo]

On Thursday, January 10, 2013 11:30:35 Mark wrote:
> very rapidly, the actual view is still barely usable as long as files
> are dripping in. This is the same in QML (ListView) as in QWidgets
> The issue here is that the view - even though it's not
> showing the items - is doing all the calculations for every item
> added

if so, then the QML is being done "wrong" in some way. the default views in 
QML (along with some we've written ourselves) only creates delegates for items 
that are shown along with +/-N pages for caching (so when you scroll you don't 
see things updating; the updates are happening N pages further down the 
scrolling)

under no circumstances should the entire set of icons be laid out at any time. 
memory usage and CPU usage simply prohibits this, as you noted :)

QML makes it really simple to just lay out what is needed (shown +/- some 
scroll-ahead pages); this in turn makes it easier to write the model so it is 
lazy loading: only load the essentials (even progressively; QML views handle 
this just fine) and then when requested load details.

because QML binds data to properties, the async nature of this does not cause 
further complexity in your code: it all happens in the QML runtime. a new 
delegate is made for a given index (automatically based on scrol position and 
view size), it binds to the data for that index, the model then knows 
something has requested that data and goes to fetch it (whenever/however it 
feels :) and when it updates that data then the delegate also automatically is 
updated .. all without dealing with paint events and other annoyances of views 
with delegates written in the imperative style.

this allows huge (even "infinite"!) size models to be written that feed views 
that are performant even on mobile devices ... with very little effort.

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.) 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.)

also, the model itself can process some statistics (e.g. longest name) as it 
loads. this can be put into a Q_PROPERTY that the QML can then access. with 
C++/QWidget, the annoyance with this approach is then you need to reference 
the C++ object with the exact type and you end up welding models and views 
together and .. with QML all the properties are dynamic. you can test for 
their existence and use them if they are there ... and this is also rather 
efficiently implemented.

all of this is a very long-winded way of saying:

	if you do QML correctly and write the model accordingly,
	you should be able to have a stupidly fast view.
	(at least from the user's perspective :)

i know because i've seen QML views on models with millions of entries 
scrolling insanely smoothly with complex and beautiful delegates. i've also 
helped write a couple. including doing it "wrong" a few times while learning 
:)

-- 
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/991e7f4d/attachment.sig>