Re: changing GtkTable homogeneous expand behaviour

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Fri, 8 Feb 2002, Owen Taylor wrote:
> 
> > >       if (nexpand > 0)
> > >         {
> > >           width = real_width;
> > > 
> > >           for (col = 0; col + 1 < table->ncols; col++)
> > >             width -= table->cols[col].spacing;
> > > 
> > >           for (col = 0; col < table->ncols; col++)
> > >             {
> > >               extra = width / (table->ncols - col);
> > >               table->cols[col].allocation = MAX (1, extra);
> > >               width -= extra;
> > >             }
> > >         }
> > >     }
> > >   else
> > >   [...]
> > > 
> > > towards nexpand always being TRUE.
> > > 
> > > alternatively, we could add a property ::homogeneous_expand
> > > that enforces this, but i don't see any practical uses in not
> > > having that flag turned on.
> > 
> > I've only ever actually used a homogenous table once to my memory, so
> > I doubt this will affect a lot of people.
> > 
> > This change seems to have a neutral effect on the actual capabilities
> > involved:
> > 
> >  - Without the change, if you set your children to expand, you wil
> >    get the same behavior as after the change.
> >  - With the change, you can get the old behavior back by sticking
> >    your table in the alignment.
> > 
> > If doing things form scratch, I agree that the simpler "ignore expand
> > and fill flags for homogenous tables" would be better, but I do wonder
> > if it's right to change it now. 
> > 
> > It doesn't add functionality and it could break someone's layout.
> 
> well as you said, you could get the old behaviour back by adding
> the table to an alignment (or by packing the table without FILL options
> into it's parent).
> but what's the actual "breakage" if the alignment is omitted?
> 
> aside from empty tables, the only effect this will have is on homogeneous
> tables without a single EXPAND child to evenly distribute the extra allocated
> space between all its rows and columns and grow as a whole in contrast
> to ignoring the extra space and letting it sum up as an empty area to
> its left and bottom.
> i suppose, if you really want a homogeneous table that doesn't grow with
> the size it's allocated, you most probably:
> 1) wouldn't pack it with FILL into its parent in the first place (so this
>    wouldn't actually change)
> 2) would want the overfull space to distribute evenly between left/right of
>    the table or top/bottom of it. but that requires packing the table into
>    an alignment already.
> 
> so as i said, i don't see a _practical_ use case for the current behaviour
> and thus don't envision actual breakage. but even if there were a case like
> this, the only thing that'd possibly happen is it's all children growing
> homogeneously which usually doesn't decrease usability.

It's not guaranteed that every widget packed in there will be able to
grow meaningfully if someone didn't expect it to grow. It might be
a custom widget where the drawing code doesn't handle that.

Or you might just not want expansion because expansion doesn't look good.

Anyways, my feeling is that this is is somewhat pathological border
case, and the decision in what to do with it basically arbitrary.

My objection is not that your suggested change is wrong. But simply that
we made the decision about this border case in the past and in absence
of a hard-and-fast right vs. wrong criterion, we should stick with that
decision and avoid possibly affecting layouts that are working as
desired.

Anyways, if you feel strongly about it, go ahead. I doubt anybody will
notice one way or the other.
 
> > > as an aside, to make derivation from GtkTable less hacky, we should
> > > really invoke the seperate size requisition and size allocation passes
> > > through a class method pointer.
> 
> > That would completely prevent us from doing things like fixing the
> > current brokeness in calculating requests and allocations in the
> > presence of row-spanning children. (Bug #1261.)
> 
> while i agree that we should fix #1261, the amount of possible breakage
> with this change will be far higher than in the case i outlined above,
> because fixing that bug will to a huge extend change the current behaviour
> of how extra space is distributed between its children.

Well, the difference is that your change doesn't actually remove or add 
functionality, so the only difference is changing a behavior that you found
unexpected. Some other people might find it unexpected that you get
expansion when no expansion was specified.

While the row-spanning bugs are really just completely wrong computations.
(Even EXPAND out of the picture). If I have a table:

 AAAA AAAA| DDDD
 ----+----+----
 CCCC|BBBB  BBBB

With the requested widths:

 A = B = 20
 C = D = 1

I think anyone would expect to get the column widths 1,19,1. Currently you
get something like 6,14,10: too much space and it isnt' even symmetric.

Unfortunately, the difference is also that computing row-spanned table layouts
is reasonably hard algorithmically. (Though clearly someone has solved it
before....)

Regards,
                                        Owen