[Development] New class for QtWidgets: ColumnResizer

[Oswald Buddenhagen]

On Fri, Jun 13, 2014 at 10:39:34AM +0200, Aurélien Gâteau wrote:
> Oswald Buddenhagen wrote:
> > On Thu, Jun 12, 2014 at 04:08:17PM +0200, Aurélien Gâteau wrote:
> >> Olivier Goffart wrote:
> >> > But just wondering if it would not be better to have that as an API
> >> > within QGridLayout such as
> >> >   QGridLayout::setAlignedWith(QGridLayout*)
> >> 
> >> The class works with QFormLayout as well, so I don't think moving the
> >> feature into QGridLayout would be a good idea.
> >> 
> > they have a common base class, you know ...
> > 
> >   QLayout::linkDimension(QLayout *other, Qt::Orientation orientation =
> >   Qt::Horizontal)
> > 
> > (the second parameter is actually a flag field).
> > 
> > and for more fine-grained control one could consider (not sure this makes
> > sense):
> > 
> >   QLayoutItem::linkDimension(QLayoutItem *other, Qt::Orientation
> >   orientation = Qt::Horizontal)
> 
> What is missing from what you propose is the notion of column or row: 
> ColumnResizer lets you limit resizing to one column only so for example if 
> you have two 3-columns QGridLayouts stacked on top of each other then you 
> can link the first column widths while leaving each layout decide how they 
> want to size the 2 other columns.
> 
linking layout items would do exactly that, no? obviously, in a grid
layout, linking an item's width constrains the whole column's width.
of course one could argue that this is less elegant.

> What about this instead?
> 
>     QLayout::linkDimension(QLayout *other, int index, Qt::Orientation 
> orientation = Qt::Vertical);
> 
could work, i guess.

the default orientation is meant to link the width, as i think that's
the by far more common case. whether one calls that horizontal or
vertical is an awesome bikeshed, as we have seen in various discussions
about splitters. my thinking was "width is horizontal on the screen".

> > but then, i wonder whether you are fixing the right problem to start
> > with. usually, one would create a big master layout, and embed
> > sublayouts spanning multiple cells in the areas that are not supposed to
> > be contrained by the grid.
> 
> As Eike pointed out: using a big grid means you have to give up on group 
> boxes.
> 
yes, this is indeed a problem. to make that work, one would have to
apply the grid to the "inner" widgets, but still consider the frames,
etc. in the calculation - that would be somehow represented as
margins/spacings, i suppose. it's obviously a bigger project ...