[Interest] a few questions about QML Components

[André Somers]

Hi,

jensbw at gmail.com schreef op 21-5-2014 10:49:
> Quick.Controls 1.2 (Qt 5.3) introduces TableView::resizeColumnsToContens() and TableViewColumn::resizeToContents().
>> Stupid question probably, but why arn't these written in a declarative way?
>>
>> André
> Certainly not a stupid question and I think I could pitch in on why I think they are done this way.
>
> Just like with widget item views, adjustToColumns only adjusts to the currently visible content as it involves querying all the visible items for their implicit size hints and adjusting to the largest one. This is also what happens when the user double clicks on a column resize handle. Remember that table view doesn’t know the size hints of the potentially millions of items that are yet to be scrolled into view.
>
> An imperative approach lets the user decide exactly when the columns should be adjusted, which is usually right after setting the model.
>
> In addition, the user generally does not expect table view headers to expand or change while they are scrolling the table view. If this was a declarative property, you would either not have any control of exactly when to do so and the alternative would be to continuously adjust to contents during scrolling which would also carry a big performance cost.
>

Thanks for your reply. I get the implications, but I must say that I 
really don't like the introduction of imperative methods like these into 
Quick components. I think it undermines the whole idea of using QML to 
specify the UI. You suggest to adjust the columns "right after setting 
the model", but in a declarative UI, you don't control when the model is 
set. The model is bound to the view, and that is the state. Right? 
Furthermore, the contents of the model may change after setting it on 
the view as well.

I get the performanceimplications of querying potentially millions of 
items for a width. I also get that anyone designing a GUI that actually 
shows millions of items in a single table and expect the user to 
navigate that, is not worth his paycheck. No matter when you call that 
imperative method, that is going to have an impact in that scenario 
anyway. You'd be better of specifying a sane default width for that 
column and use a delegate that's smart enough to use the space it has in 
a sane way in that case.

My feeling is that a declarative method that allows you to specify the 
resizing behaviour would have made more sense: continiously adapt to 
what's visible, do it once for the whole set, not automatically at all, 
or even more strategies. That allows you to tune the behaviour and 
associated tradeoffs against the envisioned use for that view. The 
developer or designer will, after all, know if a view is likely to 
display the order of magnitude of 10, 1.000 or 1.000.000 rows. There is 
no reason to go for an imperative API because a few designers may end up 
doing the lattter.

André