Re: Extended Layout Summary

On Tue, 2007-11-20 at 17:13 +0100, Mathias Hasselmann wrote:
> For supporting your feature there should be a separate call:
> 	void (*get_supported_sizes) (GtkOrientation   orientation,
>                                      GtkRequisition **sizes,
> 				     guint           *n_sizes);

A couple of points:

1.  Don't be hasty abut this.

Consider having a bunch (m) of multiple-natural-sized widgets (each with
"n" different natural sizes) within a single container.  This means that
there are n^m possible "natural sizes" for the container.  You get to a
point where the natural sizes given would almost form a continuum across
all possible values.  It gets worse when you consider that the value "n"
itself is possibly exponential (2 to the power of number of possible

What would this extra information do for you?  What I mean: how would
your updated decision-making algorithm for boxes look?

2.  I think having my buttons a bit wider on the window switcher is a
gain.  I'd happily take the extra space.  In the case that the wnck
applet gets this space it should use it.

3.  Another example worth considering is toolbars.  Their minimum size
is the size at which they show the [v] drop-down and nothing else.
Their natural size is obviously showing all of their icons.  If they
were to have multiple natural sizes it would be showing 1, 2, 3, 4...

I guess it's not too uncommon for people to want to stack multiple
toolbars together horizontally (I've witnessed at least 2 people asking
in #gtk+ about this before).

If you share the extra space (above minimum) evenly then you are doing
yourself a disservice.  Assume for a moment that each dropdown takes as
much space as a single toolbar button.  We want to stack 3 toolbars
together with buttons {a, b, c, d}, {1, 2, 3, 4} and {w, x, y, z}.  We
are allocated enough space to show 9 buttons.

Is it better to have:

[a] [b] [V] [1] [2] [V] [w] [x] [V]   (3 buttons wasted on dropdowns)


[a] [b] [c] [d] [1] [2] [3] [4] [V]   (only 1 button wasted)

Note that you cannot solve this with "expand" or "fill" flags alone,
because what do you do?  Set the left-most widget expand/fill but not
the others?  In this case the layout doesn't know to give space to the
second on before the third.  If you set all but the very right-most one
expand/fill then the layout doesn't know to give to the leftmost before
the centre one...

Maybe each widget can have some sort of a "weight" within the container
that specifies the slice of the pie it gets... but even this doesn't
help.  Maybe "priority" so that nobody gets any extra space until
everyone of higher priority has their full natural size?

For things like toolbars, wnck window list and so on, it's very unclear
what the "correct" thing to do it.  You could spend a very long time
thinking about it and still not find an elegant solution.  This is
definitely no time to go blindly adding new API. :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]