Expanding items of wx[Flex]GridSizer in one direction only

74 views
Skip to first unread message

Vadim Zeitlin

unread,
Jan 26, 2015, 10:43:59 AM1/26/15
to wx-dev
Hello,

There have been a couple of discussions and at least one patch
(http://trac.wxwidgets.org/ticket/15415) about allowing to expand the items
of wx[Flex]GridSizer in only a single direction and not necessarily both at
once as wxEXPAND currently does. The standard answer always was that it was
possible to achieve this by puting a nested sizer with wxEXPAND flag into
wxGridSizer and then centering the real contents inside that sizer, and
this definitely works -- but also seems too much work for what is probably
a rather common case.

I wasn't greatly enthusiastic about the solutions proposed so far (see
again #15415), but thinking more about this, I can't help wondering why
we couldn't just allow combining wxEXPAND and wxALIGN_CENTER_VERTICAL (or
HORIZONTAL, of course, but VERTICAL is much more commonly useful) to work
in the natural way. Currently wxEXPAND overrides any other alignment flags
and makes the item expand in both directions, but this doesn't have to work
like this, does it?


So I wonder if we would break anything important by making wxEXPAND apply
only in the direction for which no either alignment is specified, i.e., to
be precise, if wxEXPAND is given then:

1. If wxALIGN_CENTER_VERTICAL or wxALIGN_BOTTOM is also given, then the
item is only expanded horizontally.

2. If wxALIGN_CENTER_HORIZONTAL or wxALIGN_RIGHT is also given, then the
item is only expanded vertically.

3. If flags from both groups are given, then we assert as this doesn't
make sense.

This seems like a much simpler (than #15415), consistent and easy to use
solution.

What do you think?
VZ

Manolo

unread,
Jan 26, 2015, 1:19:05 PM1/26/15
to wx-...@googlegroups.com
Sorry, I don't agree. IMHO 'alignment' stands for 'position', while
'expand' stands for 'size'. Mixing both flags adds more confusion to the
sizers subject (Yeah, sizers is a common FAQ, perhaps because wx lacks a
sizers sample ;( )

I like the idea of using wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
not only for wxGridSizer (and derivatives) but for the base class
wxSizer. I think it may clarify a bit the grow direction.

Using wxEXPAND_HORIZONTALLY in a wxBoxSizer(wxHORIZONTAL) for an item
added with proportion=0 would had no effect, while with proportion>0 it
would behave as currently code ever did.
Using wxEXPAND_VERTICALLY in a wxBoxSizer(wxHORIZONTAL) with any
proportion would behave as wxEXPAND.

For grid-sizers family, wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
would allow to control the growing of each individual item (not of its
field), something that currently must be done using another sizer inside
the field for that item. With this, item proportion wouldn't be useless
any more.

Regards,
Manolo

Vadim Zeitlin

unread,
Jan 26, 2015, 1:24:01 PM1/26/15
to wx-...@googlegroups.com
On Mon, 26 Jan 2015 19:19:01 +0100 Manolo wrote:

M> Sorry, I don't agree. IMHO 'alignment' stands for 'position', while
M> 'expand' stands for 'size'. Mixing both flags adds more confusion to the
M> sizers subject

It's a bit too late to avoid mixing them as this was the case since the
beginning.

M> I like the idea of using wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
M> not only for wxGridSizer (and derivatives) but for the base class
M> wxSizer. I think it may clarify a bit the grow direction.

Using them for box sizers would be totally confusing as the one
corresponding to the minor direction of the sizer would affect the item
proportion. So now, instead of mixing "just" alignment and size, you'd mix
everything together.

M> Using wxEXPAND_HORIZONTALLY in a wxBoxSizer(wxHORIZONTAL) for an item
M> added with proportion=0 would had no effect, while with proportion>0 it
M> would behave as currently code ever did.
M> Using wxEXPAND_VERTICALLY in a wxBoxSizer(wxHORIZONTAL) with any
M> proportion would behave as wxEXPAND.

Just no. 1D sizers currently are maybe not very intuitive but at least
they are consistent and easy to explain and understand once you are told
that the size in the major direction is affected by the proportion and only
the proportion while the flags only affect the minor direction. Sorry but
breaking this is out of question.

M> For grid-sizers family, wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
M> would allow to control the growing of each individual item (not of its
M> field), something that currently must be done using another sizer inside
M> the field for that item. With this, item proportion wouldn't be useless
M> any more.

For grid sizers these flags do make sense, but then we'd have the problem
of being able to use them only for 2D sizers but not 1D ones. IMO keeping
just wxEXPAND is preferable to this -- even if I agree that wxEXPAND
working in only minor direction for the 1D sizers and in both for the 2D
ones is not ideal.

Regards,
VZ

Manolo

unread,
Jan 26, 2015, 1:40:58 PM1/26/15
to wx-...@googlegroups.com
El 26/01/15 a las 19:23, Vadim Zeitlin escribió:
> On Mon, 26 Jan 2015 19:19:01 +0100 Manolo wrote:
>
> M> Sorry, I don't agree. IMHO 'alignment' stands for 'position', while
> M> 'expand' stands for 'size'. Mixing both flags adds more confusion to the
> M> sizers subject
>
> It's a bit too late to avoid mixing them as this was the case since the
> beginning.

I'm not speaking of wxALIGN_BOTTOM | wxEXPAND. Users don't have problems
understanding that even when the flags are combined they are used for
different goals.
I'm speaking about mixing goals: you propose to assert on some
alignment/expand combination.

>
> M> I like the idea of using wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
> M> not only for wxGridSizer (and derivatives) but for the base class
> M> wxSizer. I think it may clarify a bit the grow direction.
>
> Using them for box sizers would be totally confusing as the one
> corresponding to the minor direction of the sizer would affect the item
> proportion. So now, instead of mixing "just" alignment and size, you'd mix
> everything together.

No. Proportion is what matters in the mayor direction, despite of
whatever flag is set. Nobody is going to change this.

>
> M> Using wxEXPAND_HORIZONTALLY in a wxBoxSizer(wxHORIZONTAL) for an item
> M> added with proportion=0 would had no effect, while with proportion>0 it
> M> would behave as currently code ever did.
> M> Using wxEXPAND_VERTICALLY in a wxBoxSizer(wxHORIZONTAL) with any
> M> proportion would behave as wxEXPAND.
>
> Just no. 1D sizers currently are maybe not very intuitive but at least
> they are consistent and easy to explain and understand once you are told
> that the size in the major direction is affected by the proportion and only
> the proportion while the flags only affect the minor direction. Sorry but
> breaking this is out of question.

How my proposal breaks this? I'm only saying that wxEXPAND_VERTICALLY
could be used in an horizontal box sizer just as wxEXPAND is, with the
same meaning. And using wxEXPAND_HORIZONTALLY with this same horizontal
box has no effect, same as not using this flag.

Regards,
Manolo

Vadim Zeitlin

unread,
Jan 27, 2015, 5:52:45 AM1/27/15
to wx-...@googlegroups.com
On Mon, 26 Jan 2015 19:40:54 +0100 Manolo wrote:

M> I'm speaking about mixing goals: you propose to assert on some
M> alignment/expand combination.

Asserting is just a "QoI" issue, it's there to help people to notice that
the combination of flags they specify doesn't do anything useful. This is,
of course, not new neither, e.g. the current sizer API already allows you
to use wxALIGN_BOTTOM|wxALIGN_CENTER_VERTICAL and other nonsensical
combinations.

M> > M> I like the idea of using wxEXPAND_HORIZONTALLY and wxEXPAND_VERTICALLY
M> > M> not only for wxGridSizer (and derivatives) but for the base class
M> > M> wxSizer. I think it may clarify a bit the grow direction.
M> >
M> > Using them for box sizers would be totally confusing as the one
M> > corresponding to the minor direction of the sizer would affect the item
M> > proportion. So now, instead of mixing "just" alignment and size, you'd mix
M> > everything together.
M>
M> No. Proportion is what matters in the mayor direction, despite of
M> whatever flag is set. Nobody is going to change this.

But what would wxEXPAND_{HORIZONTALLY,VERTICALLY} do then in
horizontal/vertical sizer? Be silently ignored?

M> How my proposal breaks this? I'm only saying that wxEXPAND_VERTICALLY
M> could be used in an horizontal box sizer just as wxEXPAND is, with the
M> same meaning. And using wxEXPAND_HORIZONTALLY with this same horizontal
M> box has no effect, same as not using this flag.

OK, I misunderstood your proposal, although I do have to say that this:

M> Using wxEXPAND_HORIZONTALLY in a wxBoxSizer(wxHORIZONTAL) for an item
M> added with proportion=0 would had no effect, while with proportion>0 it
M> would behave as currently code ever did.

seemed to be quite different from the above.

Anyhow, I agree that making these flags do nothing in this case is a
lesser evil, but we'd still need to detect their use and assert to ensure
that nobody expects them to work. And nevertheless some people still would
and you can't really blame them, it seems pretty natural to use
wxEXPAND_HORIZONTALLY to make an item expand in the horizontal direction.

Allowing "constraining" the use of wxEXPAND in 2D sizers doesn't suffer
from this problem, at least I don't see what kind of wrong usage in 1D case
it could expire. And it doesn't require the introduction of 2 new flags. So
for me it is better from all points of view.

Regards,
VZ

Vadim Zeitlin

unread,
Apr 4, 2015, 1:22:01 PM4/4/15
to wx-...@googlegroups.com
Hello,

Better late than never: I've finally implemented my proposal[*] to allow
combining wxEXPAND with alignment flags in wxGridSizer, so that it is now
possible to use e.g. wxSizerFlags().Expand().CentreVertical() (the latter
method is also a new addition) to do the expected thing.

The changes are at http://review.wxwidgets.org/r/607/ and any comments are
welcome but I want to commit this relatively soon (Wednesday at the latest
but preferably sooner).

Thanks in advance for your feedback,
VZ

[*] See http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/161320/ for
the beginning of this thread.
Reply all
Reply to author
Forward
0 new messages