Hi, jen...@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é _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
