wxSizer improvements
mr cool
(s) of various types. I will implement these changes if I receive
approval, but I'm not going to bother otherwise.
i) wxSizerFlags::Border should be renamed wxSizerFlags::Margin. I tend
to think a border is a visible item.
ii) wxSizerFlags::Expand(void) should be changed to
wxSizerFlags::Expand(int direction=wxALL), taking an argument for
wxVERTICAL and / or wxHORIZONTAL
iii) wxSizer::Add(wxSizer*) overload should have a default flag of
(wxEXPAND | wxALL)
mc
Vadim Zeitlin
mc> I'd like to suggest a couple of changes to the api as regards wxSizer
mc> (s) of various types. I will implement these changes if I receive
mc> approval, but I'm not going to bother otherwise.
mc>
mc> i) wxSizerFlags::Border should be renamed wxSizerFlags::Margin. I tend
mc> to think a border is a visible item.
There is some truth in this however it's nearly not enough to introduce a
duplicate API which would use a different term from what anybody who ever
used wx is familiar with.
mc> ii) wxSizerFlags::Expand(void) should be changed to
mc> wxSizerFlags::Expand(int direction=wxALL), taking an argument for
mc> wxVERTICAL and / or wxHORIZONTAL
This makes absolutely no sense for 1D sizers and currently is not
supported for 2D ones so it doesn't seem like a good idea. Also, wxALL
belongs to a different enumeration than wxVERTICAL and wxHORIZONTAL so
mixing them is not recommended.
mc> iii) wxSizer::Add(wxSizer*) overload should have a default flag of
mc> (wxEXPAND | wxALL)
This is impossible because of all the existing code using this function
which would be broken (changed, if you prefer, but this is the same thing
in this context) by such change.
Please consider implications of your proposals on millions (at least)
lines of the existing code using the library if you want them to be
considered seriously.
Thanks,
VZ
mr cool
existing code, and I think it's okay to do that when you advance a
major version. I have come across examples of that in the past. It is
often more important to improve the api than to maintain backwards
compatibility.
The purpose of wxSizerFlags::Expand() is to cause the widget to expand
to fill the compartment allocated to it by the sizer. It makes sense
for both box and grid sizers. I don't see what the problem is I'm
afraid.
mc
On Nov 7, 10:20 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> < 1KViewDownload
Vadim Zeitlin
mc> I appreciate that sometimes changes to the api alter the behaviour of
mc> existing code, and I think it's okay to do that when you advance a
mc> major version.
It's ok to break compatibility in a new major release if the benefit is
big enough. But the benefits of the changes you proposed were vanishingly
small, most of them could be described as subjective preferences. So they
definitely fell very short of the threshold.
mc> The purpose of wxSizerFlags::Expand() is to cause the widget to expand
mc> to fill the compartment allocated to it by the sizer. It makes sense
mc> for both box and grid sizers. I don't see what the problem is I'm
mc> afraid.
In box sizers the behaviour of the item in its major direction is entirely
determined by its proportion. So wxSizerFlags(1) will always expand
horizontally in a wxBoxSizer(wxHORIZONTAL), whether you use Expand() or
not. And making Expand() overlap with the functionality of the ctor would
be a very poor idea from the point of view of good API design.
Regards,
VZ
mr cool
> In box sizers the behaviour of the item in its major direction is entirely
> determined by its proportion. So wxSizerFlags(1) will always expand
> horizontally in a wxBoxSizer(wxHORIZONTAL), whether you use Expand() or
> not. And making Expand() overlap with the functionality of the ctor would
> be a very poor idea from the point of view of good API design.
>
(wxHORIZONTAL), and I think this behaviour is dubious: it forces you
to have an expansion and you may not want this. I think by default
there should be no expansion, and if you want expansion, you set it
with a call to wxSizer::Expand(int direction).
regards,
mc.
Vadim Zeitlin
mc> Indeed, it does always expand horizontally in a wxBoxSizer
mc> (wxHORIZONTAL), and I think this behaviour is dubious: it forces you
mc> to have an expansion and you may not want this. I think by default
mc> there should be no expansion, and if you want expansion, you set it
mc> with a call to wxSizer::Expand(int direction).
This would be something very different from the existing sizer classes. I
don't say it has no merit but this is just plainly incompatible with the
idea of using proportions for the items as wxBoxSizer does. Maybe you can
write your own sizer class behaving like this but clearly this can't be
changed in wxBoxSizer itself.
Regards,
VZ
mr cool
classes work. It only affects how the widget appears within the
compartment allocated for it by the sizer. The compartment size is
dependent upon the proportion allocation. The wxSizerFlags::Expand
function specifies how the widget appears within that allocation, and
whether it should expand beyond its minimum size to fill the space
allocated by the sizer. I am not suggesting any change to the way
proportion is interpreted by the sizer.
My suggestion is a minor change. I don't think you understand what is
going on here.
mc
On Nov 8, 3:30 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> < 1KViewDownload
Vadim Zeitlin
mc> Actually wxSizerFlags::Expand() doesn't alter the way the sizer
mc> classes work. It only affects how the widget appears within the
mc> compartment allocated for it by the sizer. The compartment size is
mc> dependent upon the proportion allocation. The wxSizerFlags::Expand
mc> function specifies how the widget appears within that allocation, and
mc> whether it should expand beyond its minimum size to fill the space
mc> allocated by the sizer.
It doesn't work like this today, please test it before continuing this
discussion.
mc> My suggestion is a minor change. I don't think you understand what is
mc> going on here.
The feeling is mutual.
Regards,
VZ
mr cool
mc
On Nov 8, 10:47 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> < 1KViewDownload