[Interest] a few questions about QML Components
andre at familiesomers.nl
Wed May 21 11:51:31 CEST 2014
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?
> 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.
More information about the Interest