Re: changing GtkTable homogeneous expand behaviour

[Tim Janik <timj gtk org>]

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.

> > 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.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ