[pygtk] Gtk.Box, homogeneous and expand
Jérôme
There's something I don't get with the behaviour of homogeneous in Gtk.Box. I
guess there must be a reason for it working this way. I just don't get the
logic.
From http://pygtk.org/pygtk2tutorial/sec-DetailsOfBoxes.html :
"The homogeneous argument [... ]controls whether each object in the box has
the same size."
"If homogeneous is set, then "the pack routines function essentially as if
the expand argument was always turned on."
Though it works "as if the expand argument was always turned on", "each
object in the box has the same size" is not really what I see.
What I see :
----------
1.a/
homogeneous = True
expand = whatever
fill = False (for all objects)
-> Objects are scattered along the line (it is a HBox), with space in
between. They may be provided equal space, but don't actually fill it, so
they appear with different sizes.
[ |a| |abc| || ]
1.b/
homogeneous = True
expand = whatever
fill = True (for all objects)
-> Objects use all the line and are of equal size
[| a || abc || | ]
What I would expect :
-------------------
2.a/
homogeneous = True
expand = False
fill = whatever
-> Objects would be of the same size : the size of the largest one, and they
would be left-aligned (pack_start() being used).
[| a ||abc|| | ]
2.b/
homogeneous = True
expand = True
fill = False
-> Objects would be of the same size : the size of the largest one, and they
would be scattered along the line with space in between.
[ | a | |abc| | | ]
2.c/
homogeneous = True
expand = True
fill = True
-> Objects would be of the same size and fill the line.
[| a || abc || |]
This seems more logical to me. I can't figure out why it does not work this
way.
Besides, I don't see how to obtain 2.a/ any other way.
Am I the only one who would expect things to work this way (or at least a
different way) ?
--
Jérôme
_______________________________________________
pygtk mailing list py...@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Pietro Battiston
> Hi.
>
> There's something I don't get with the behaviour of homogeneous in Gtk.Box. I
> guess there must be a reason for it working this way. I just don't get the
> logic.
I may be wrong, but to me it looks the logic is much simpler than what
you expect. You expect a left alignment, but there is no reason why it
should be. If I understand correctly, "pack_start" and "pack_end" refer
to the _order_ of widgets, and not to any alignment of the widgets as a
whole.
So if there is no left/right alignment rule, the default is just to
distribute them on all the available space, leaving the same empty space
among them or, if you instead set "homogeneous", allocating to each the
same space, which will then possibly be partly empty.
Your logic could make sense, it is just based on more assumptions.
> [...]
> What I would expect :
> -------------------
>
> 2.a/
> homogeneous = True
> expand = False
> fill = whatever
> -> Objects would be of the same size : the size of the largest one, and they
> would be left-aligned (pack_start() being used).
>
> [| a ||abc|| | ]
>
> [...]
>
> This seems more logical to me. I can't figure out why it does not work this
> way.
>
> Besides, I don't see how to obtain 2.a/ any other way.
>
(craf already replied to you, but I had already wrote what follows:)
I see at least 2 ways: turn the "homogeneous" flag off, and all "expand"
to the False, then
1) put the last object in a GtkAlignment, make it (the child) appear on
the left, and the "Expand" flag of the GtkAlignment to True, or
2) pack, after the last object, another GtkAlignment, or even a
DrawingArea or a Label (again, with the "Expand" flag to true).
I anticipate that your reaction will be "but those are ugly hacks", and
I guess - but again, I might be wrong - the answer of the developers
would be "what you're trying to do is ugly".
bye
Pietro
Jérôme
Pietro Battiston a écrit:
> So if there is no left/right alignment rule, the default is just to
> distribute them on all the available space, leaving the same empty space
> among them or, if you instead set "homogeneous", allocating to each the
> same space, which will then possibly be partly empty.
>
> Your logic could make sense, it is just based on more assumptions.
The GTK3 docs says :
http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/layout.html#boxes
"If homogeneous is True, all widgets in the box will be the same size, of
which the size is determined by the largest child widget."
That's why I would expect homogeneous to mean widgets (for instance buttons)
of same size, regardless of expand, as I described in my previous message.
This description does not seem to fit reality. In practice, we saw that when
homogeneous is set, the N widgets are provided one Nth of the total size,
though they don't necessarily fill that space, and this size does not depend
on the largest child widget.
Well, thinking of it, it does, if the total width is determined by the
widgets, which happens if the HBox is the largest. This is not true if it
belongs to a VBox with larger HBoxes in it, of if I enlarge the window, for
instance.
> I anticipate that your reaction will be "but those are ugly hacks",
But those are ugly hacks !
> and I guess - but again, I might be wrong - the answer of the developers
> would be "what you're trying to do is ugly".
Is it ? Perhaps.
I had the feeling that the logic I exposed allowed more things to be done
with the same amount of parameters. I must be wrong, since people have been
working on it much longer than I did. I just don't see why.
Anyway, thanks for answering. At least it confirmed I had not missed anything
obvious.
--
Jérôme
Pietro Battiston
> Tue, 03 Jan 2012 16:34:37 +0100
> Pietro Battiston a écrit:
>
> > So if there is no left/right alignment rule, the default is just to
> > distribute them on all the available space, leaving the same empty space
> > among them or, if you instead set "homogeneous", allocating to each the
> > same space, which will then possibly be partly empty.
> >
> > Your logic could make sense, it is just based on more assumptions.
>
> The GTK3 docs says :
> http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/layout.html#boxes
>
> "If homogeneous is True, all widgets in the box will be the same size, of
> which the size is determined by the largest child widget."
>
> That's why I would expect homogeneous to mean widgets (for instance buttons)
> of same size, regardless of expand, as I described in my previous message.
>
> This description does not seem to fit reality. In practice, we saw that when
> homogeneous is set, the N widgets are provided one Nth of the total size,
> though they don't necessarily fill that space, and this size does not depend
> on the largest child widget.
Yes, you're right, strictly speaking the docs are wrong: widgets are
_allocated_ the same size, they wont't _be_ the same size. That said, it
is clear that that sentence from the doc _couldn't_ be right, because a
widget has the "power" to not expand and hence the Box couldn't
determine its true size anyway: it can only decide how much space to
allocate to it.
>
> Well, thinking of it, it does, if the total width is determined by the
> widgets, which happens if the HBox is the largest. This is not true if it
> belongs to a VBox with larger HBoxes in it, of if I enlarge the window, for
> instance.
>
> > I anticipate that your reaction will be "but those are ugly hacks",
>
> But those are ugly hacks !
>
> > and I guess - but again, I might be wrong - the answer of the developers
> > would be "what you're trying to do is ugly".
>
> Is it ? Perhaps.
>
> I had the feeling that the logic I exposed allowed more things to be done
> with the same amount of parameters. I must be wrong, since people have been
> working on it much longer than I did. I just don't see why.
You seem to be right on this too: your rule could apparently allow more
things. And in fact, my sentence is exagerated: certainly what you want
to do is not necessarily "ugly" (and in fact, the solution by craf is
less ugly than the one by me), Let's just say that:
1) I'm not sure what you see as a "sane" rule still looks so obvious
when we stop assuming that all children share the same flags (not to
mention the fact that in a table we have the same problem in 2
dimensions, and we expect a behaviour coherent with onedimensional
GtkBoxes)
2) the gtk libs seem to not favour what seems to not be considered as a
logic default: if there is no _logic_ difference between widgets on the
left and on the right, then they should be nicely distributed on all the
available space, while if they are logically different then they will be
separated in different containers (and at this point, GtkFrames are
probably even better suited than nested GtkBoxes).
bye
Pietro
Jérôme
Pietro Battiston a écrit:
> Yes, you're right, strictly speaking the docs are wrong: widgets are
> _allocated_ the same size, they wont't _be_ the same size. That said, it
> is clear that that sentence from the doc _couldn't_ be right, because a
> widget has the "power" to not expand and hence the Box couldn't
> determine its true size anyway: it can only decide how much space to
> allocate to it.
It is now much clearer to me now what "homogeneous", "expand" and "fill" mean.
I understand the logic of it all and why my logic did not conform to it.
I still think the doc is misleading. Especially the GTK3 doc, where the
difference between expand and fill is unclear (to me) :
http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/layout.html#boxes
Thank you both for taking the time to answer.
--
Jérôme
Jérôme
Pietro Battiston a écrit:
> Yes, you're right, strictly speaking the docs are wrong: widgets are
> _allocated_ the same size, they wont't _be_ the same size. That said, it
> is clear that that sentence from the doc _couldn't_ be right, because a
> widget has the "power" to not expand and hence the Box couldn't
> determine its true size anyway: it can only decide how much space to
> allocate to it.
There's a specific widget that can be used to pack buttons making them have
all the same size.
http://developer.gnome.org/gtk3/stable/GtkButtonBox.html
This is just what I wanted.
(It only works for buttons.)
--
Jérôme