[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 scrollarea-sizehint.patch Description: Binary data -- Christoph Schleifenbaum | 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
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
On Thursday, December 22, 2011 18:06:51 Christoph Schleifenbaum wrote: > 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? Just bumping this. The patch is in Gerrit http://codereview.qt-project.org/#change,11763 Apart from the layouting use case, the method would make it easier to implement 'Frozen columns' in itemviews using multiple views which interact with each other. I know that there is an example in Qt for that, but that has some inflexibility, such as it needs to call setHorizontalScrollMode(ScrollPerPixel); setVerticalScrollMode(ScrollPerPixel); frozenTableView->setVerticalScrollMode(ScrollPerPixel); so you are no longer in control of your scroll mode. This proposed method would make it possible to implement the scrollbars properly on the container view (which is the issue the example dodges). Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
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] On Behalf Of ext Christoph Schleifenbaum Sent: 22. desember 2011 18:07 To: 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 | 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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. Comments? Christoph 6 jan 2012 kl. 14:20 skrev : > 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] On > Behalf Of ext Christoph Schleifenbaum > Sent: 22. desember 2011 18:07 > To: 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 | 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 -- Christoph Schleifenbaum | 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
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 : > 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] On > Behalf Of ext Christoph Schleifenbaum > Sent: 22. desember 2011 18:07 > To: 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 | 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 -- Christoph Schleifenbaum | 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
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
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 mailto: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
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
Hi, ok, I added a adjustSizePolicy property. Please have a look: http://codereview.qt-project.org/12971 Cheers, Christoph 11 jan 2012 kl. 12:09 skrev : > 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 > : > > > 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] On > Behalf Of ext Christoph Schleifenbaum > Sent: 22. desember 2011 18:07 > To: 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 | 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 > > -- > Christoph Schleifenbaum | 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 > -- Christoph Schleifenbaum | 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
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
It's not quite right. sizeHint() should *always* (regardless of visibility) return a sensible value. For the interested, further details can be seen in my comment in the patch. regards, Jan-Arve From: ext Christoph Schleifenbaum [mailto:christoph.schleifenb...@kdab.com] Sent: 12. januar 2012 15:19 To: Saether Jan-Arve (Nokia-MP/Oslo) Cc: development@qt-project.org Subject: Re: [Development] sizeHint for QAbstractScrollArea, especially item views Hi, ok, I added a adjustSizePolicy property. Please have a look: http://codereview.qt-project.org/12971 Cheers, Christoph 11 jan 2012 kl. 12:09 skrev mailto:jan-arve.saet...@nokia.com>> mailto:jan-arve.saet...@nokia.com>>: 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<mailto: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 mailto: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 -- 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
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
Hi,
sizeHint() is returning a valid sizeHint, regardless the scroll area's
visibility:
QSize QAbstractScrollArea::sizeHint() const
{
Q_D(const QAbstractScrollArea);
if (!d->sizeHint.isValid() || d->sizeAdjustPolicy ==
QAbstractScrollArea::AdjustToContents) {
const int f = 2 * d->frameWidth;
const QSize frame( f, f );
const QSize scrollbars( d->vbarpolicy == Qt::ScrollBarAlwaysOn ?
d->vbar->sizeHint().width() : 0,
d->hbarpolicy == Qt::ScrollBarAlwaysOn ?
d->hbar->sizeHint().height() : 0 );
d->sizeHint = frame + scrollbars + viewportSizeHint();
}
return d->sizeHint;
}
If it's not valid (or the other comparison is true) it's getting calculated and
saved. If the saved value is valid, it gets returned directly.
Christoph
12 jan 2012 kl. 16:11 skrev :
> It's not quite right. sizeHint() should *always* (regardless of visibility)
> return a sensible value.
> For the interested, further details can be seen in my comment in the patch.
>
> regards,
> Jan-Arve
>
> From: ext Christoph Schleifenbaum [mailto:christoph.schleifenb...@kdab.com]
> Sent: 12. januar 2012 15:19
> To: Saether Jan-Arve (Nokia-MP/Oslo)
> Cc: development@qt-project.org
> Subject: Re: [Development] sizeHint for QAbstractScrollArea, especially item
> views
>
> Hi,
>
> ok, I added a adjustSizePolicy property. Please have a look:
>
> http://codereview.qt-project.org/12971
>
> Cheers,
> Christoph
>
> 11 jan 2012 kl. 12:09 skrev
> :
>
>
> 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
> :
>
>
>
> 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] On
> Behalf Of ext Christoph Schleifenbaum
> Sent: 22. desember 2011 18:07
> To: 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 | Software Engi
Re: [Development] sizeHint for QAbstractScrollArea, especially item views
Ah, sorry. For some reason I interpreted the || as && :)
So, yes, I agree with the sizeHint implementation.
12.01.12 16:20 skrev ext Christoph Schleifenbaum:
Hi,
sizeHint() is returning a valid sizeHint, regardless the scroll area's
visibility:
QSize QAbstractScrollArea::sizeHint() const
{
Q_D(const QAbstractScrollArea);
if (!d->sizeHint.isValid() || d->sizeAdjustPolicy ==
QAbstractScrollArea::AdjustToContents) {
const int f = 2 * d->frameWidth;
const QSize frame( f, f );
const QSize scrollbars( d->vbarpolicy == Qt::ScrollBarAlwaysOn ?
d->vbar->sizeHint().width() : 0,
d->hbarpolicy == Qt::ScrollBarAlwaysOn ?
d->hbar->sizeHint().height() : 0 );
d->sizeHint = frame + scrollbars + viewportSizeHint();
}
return d->sizeHint;
}
If it's not valid (or the other comparison is true) it's getting calculated and
saved. If the saved value is valid, it gets returned directly.
Christoph
12 jan 2012 kl. 16:11 skrev
mailto:jan-arve.saet...@nokia.com>>:
It's not quite right. sizeHint() should *always* (regardless of visibility)
return a sensible value.
For the interested, further details can be seen in my comment in the patch.
regards,
Jan-Arve
From: ext Christoph Schleifenbaum [mailto:christoph.schleifenb...@kdab.com]
Sent: 12. januar 2012 15:19
To: Saether Jan-Arve (Nokia-MP/Oslo)
Cc: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] sizeHint for QAbstractScrollArea, especially item
views
Hi,
ok, I added a adjustSizePolicy property. Please have a look:
http://codereview.qt-project.org/12971
Cheers,
Christoph
11 jan 2012 kl. 12:09 skrev
mailto:jan-arve.saet...@nokia.com>>
mailto:jan-arve.saet...@nokia.com>>:
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<mailto: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
mailto: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
