Oh, and be sure to describe the use case and the problem very well as it is likely that the person who will work on this issue will not want to run Python code to see the problem.
···
On 11/7/11 2:47 PM, Robin Dunn wrote:
On 11/7/11 12:31 PM, Michael Hipp wrote:
On 11/7/2011 1:32 PM, Robin Dunn wrote:
Calculating sizes and layouts in the GBS is very complicated, so it's
not too
surprising that it may need some help/hints in some cases. It's been a
long
while since I worked on it so I'm not exactly sure what is going on,
but it
probably has to do with the 2.9 change that ensures that min sizes of
items are
given precedence before free space is divided up for proportional
items. I
would not have expected that change to have this kind of effect in
grid sizers,
Would it be appropriate for me to file a Trac bug on this? I surely
isn't expected behavior. Would I file it on wxPython or wxGrigBagSizer?
Yes, go ahead and make a ticket for it. Set the component to GUI-all and
put wxGridBagSizer in the keywords.
I don't know about that Michael. To me it looks like it's talking
about knowing widget proportions, not pixels. i think it uses pixels
as a concrete example. but If you replace the numbers with proportions
perhaps that could solve your problem.
The first examples use a least common demoninator of 50 px as being
proportion 1,
The tricky thing's LCD is 25 pixels and that becomes the proportion 1
(ie cell width).
So the tricky part is that you need to increase the SPAN of larger
items to increase it's "proportional usage" of the control.
In the first examples the span was (1,2) for a 100 pixel widget
meaning it the 100 pixel widget has a proportion of 2 compared to a
proportion of 1 (50 pixel cell) widgets.
The tricky thing span was for (1,4) for the 100 pixel widget is now a
proportion of 4.
I'm going to retake a look at your code and try the GBS, something I
haven't used much.
···
On Nov 7, 12:55 pm, Michael Hipp <mich...@redmule.com> wrote:
On 11/7/2011 9:40 AM, werner wrote:
> Are you aware of this wiki page:
>http://wiki.wxpython.org/wxGridBagSizer
I was not aware of it, thanks.
...
But that page then goes on to suggest a way around this is to essentially know
the pixel-level size of things beforehand and custom tailor the sizer to that.
If I wanted to do that I might not bother with sizers at all.
Michael
Works for me using only a gridbagsizer (and the staticboxsizer) on
WinXP-SP3
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit
(Intel)] on win32
wx.version() '2.8.11.0 (msw-unicode)'
You might want to put your growablerow/cols before you add your widgets.
I don't see that as significantly better. I don't have to get out my pocket calculator to solve BoxSizers, for example.
Michael
···
On 11/8/2011 6:17 PM, DevPlayer wrote:
I don't know about that Michael. To me it looks like it's talking
about knowing widget proportions, not pixels. i think it uses pixels
as a concrete example. but If you replace the numbers with proportions
perhaps that could solve your problem.
Works for me using only a gridbagsizer (and the staticboxsizer) on
WinXP-SP3
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit
(Intel)] on win32
wx.version() '2.8.11.0 (msw-unicode)'
You might want to put your growablerow/cols before you add your widgets.
