Yes, if you think this is mostly an issue on initial show, (which I also think) then I think such a solution would acceptable. The default should then be AdjustToContentsOnFirstShow, as it is in QComboBox.
regards, Jan-Arve From: ext Christoph Schleifenbaum [mailto:christoph.schleifenb...@kdab.com] Sent: 10. januar 2012 17:19 To: Saether Jan-Arve (Nokia-MP/Oslo) Cc: development@qt-project.org Subject: Re: [Development] sizeHint for QAbstractScrollArea, especially item views Hi, thanks for your input. What do you think about adding some sizeHint policy to this? I'm thinking about as it is done for QComboBox, i.e. AdjustToContents vs. AdjustToContentsOnFirstShow. Translated to this use case would be to never return any different sizeHint (and especially never call updateGeometry()) after the scroll area is shown for the first time. 6 jan 2012 kl. 14:20 skrev <jan-arve.saet...@nokia.com<mailto:jan-arve.saet...@nokia.com>> <jan-arve.saet...@nokia.com<mailto:jan-arve.saet...@nokia.com>>: Hi, I agree that the current behavior is sometimes not optimal, but I'm not sure if this is such a good idea. With regards to behavior it has some advantages, but I believe it also has some disadvantages. And since in addition it might introduce a performance penalty I'm leaning towards that this is not a good idea. I've made a comment on the patch in gerrit: http://codereview.qt-project.org/#change,11763 Jan-Arve From: development-bounces+jan-arve.saether=nokia....@qt-project.org<mailto:development-bounces+jan-arve.saether=nokia....@qt-project.org> [mailto:development-bounces+jan-arve.saether=nokia....@qt-project.org<mailto:nokia....@qt-project.org>] On Behalf Of ext Christoph Schleifenbaum Sent: 22. desember 2011 18:07 To: development@qt-project.org<mailto:development@qt-project.org> Subject: [Development] sizeHint for QAbstractScrollArea, especially item views Hi, currently, item views do return a rather random size hint. Some at KDAB, including me, would love to see a size hint actually being related to the scroll area's content. For this, we thought of a method viewportSizeHint which returns the size of the viewport as if there would be no scroll bars required. The most common use case for this is a list or a table of data in a window: a) The ui designer doesn't need to set a custom size for the view, the size hint will make sure all data are visible b) The amount of data might grow, in that case it might made sense to enlarge the view. Imagine three tree views below each other inside a scroll area. If the tree views would stay at their size, a scroll bar would appear in both the tree view and in the surrounding scroll area. This won't happen with a proper size hint combined with a size policy. I'v attached a patch to the current qtbase.git. It does the described behaviour for QScrollArea and QTableView. Try running the example at examples/itemviews/spreadsheet to see what happens if you e.g. resize the columns in the table view. Thoughts? Cheers, Christoph -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.com<mailto:christoph.schleifenb...@kdab.com> | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.com<mailto:christoph.schleifenb...@kdab.com> | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
