Can someone show me what I'm doing wrong in the attached sample program? The two html windows are supposed to be the same size. Also attached a screenshot.
Thanks,
Michael
sizers.py (1.57 KB)
The static text forces the second column to take up that much space because of its MinSize that is determined based on the text it displays.
I've attached a modification of your example to demonstrate the point.
If this is not enough to solve your issue tell us a little more about the actual content you need in that position.
Toni
sizers.py (1.66 KB)
···
On Sun, 06 Nov 2011 19:02:57 +0100, Michael Hipp <michael@redmule.com> wrote:
Can someone show me what I'm doing wrong in the attached sample program?
The two html windows are supposed to be the same size. Also attached a
screenshot.
Thanks, Toni. But that doesn't do at all what I want. The static text now is just hidden because the size is set way too small. See attached screenshot.
What I want is for the top StaticBox to be centered across the top and have its own size appropriate to its contents and for the html boxes to be equal in size and fill all available space.
Thanks,
Michael
···
On 11/6/2011 12:15 PM, Toni Ru�a wrote:
The static text forces the second column to take up that much space
because of its MinSize that is determined based on the text it displays.I've attached a modification of your example to demonstrate the point.
If this is not enough to solve your issue tell us a little more about
the actual content you need in that position.
Here is a working version for WinXp with just boxsizers on WinXP
without the inspection.
equalhtmls.py (1.28 KB)
Try using proportion values of 1 here
···
On 11/6/11 10:02 AM, Michael Hipp wrote:
sizer.AddGrowableCol(0, 0) # size the columns equally (???)
sizer.AddGrowableCol(1, 0)
--
Robin Dunn
Software Craftsman
Thank you. Sorry I wasn't explicit, but I'm not looking for alternative implementations that work. I know there are lots of other ways to lay this out and BoxSizers are the old workhorse on things like this.
I'm trying to track down what I believe is a longstanding bug in GridBagSizer and I finally found what appears to be a fairly simple test case that shows it.
Thanks for your help,
Michael
···
On 11/6/2011 9:24 PM, Dev Player wrote:
Here is a working version for WinXp with just boxsizers on WinXP
without the inspection.
Thanks, Robin. Putting 1s there was the first thing I tried. It appears the proportion is being ignored. See attached screenshot and code.
I forgot to mention I'm on Win7, Py2.7.2, WxPy 2.9.2.4.
Thanks,
Michael
sizers3.py (1.57 KB)
···
On 11/6/2011 10:26 PM, Robin Dunn wrote:
On 11/6/11 10:02 AM, Michael Hipp wrote:
sizer.AddGrowableCol(0, 0) # size the columns equally (???)
sizer.AddGrowableCol(1, 0)Try using proportion values of 1 here
I've reduced it to a yet simpler app that shows the problem. Oddly the sizing changes somewhat on TextCtrls instead of HtmlWindows but is still wrong. Please see attached sample app and screenshot.
Win7, Py2.7.2, WxPy 2.9.2.4
Thanks,
Michael
sizers5.py (1.24 KB)
···
On 11/6/2011 12:02 PM, Michael Hipp wrote:
Can someone show me what I'm doing wrong in the attached sample program? The
two html windows are supposed to be the same size. Also attached a screenshot.
See attached, changed the span of things for the gbs, but I would probably do it like in the second one.
Werner
htmlsizerissue2.py (1.45 KB)
htmlsizerissue.py (1.36 KB)
···
On 11/07/2011 02:16 PM, Michael Hipp wrote:
On 11/6/2011 12:02 PM, Michael Hipp wrote:
Can someone show me what I'm doing wrong in the attached sample program? The
two html windows are supposed to be the same size. Also attached a screenshot.I've reduced it to a yet simpler app that shows the problem. Oddly the sizing changes somewhat on TextCtrls instead of HtmlWindows but is still wrong. Please see attached sample app and screenshot.
If that is your goal then try this one.
I don't recall but I believe that GBS has some rule that influences column size based on what you add first, i.e. in attached I am adding the long static text down to after the html/text controls.
Werner
htmlsizerissue.py (1.39 KB)
···
On 11/07/2011 02:09 PM, Michael Hipp wrote:
On 11/6/2011 9:24 PM, Dev Player wrote:
Here is a working version for WinXp with just boxsizers on WinXP
without the inspection.Thank you. Sorry I wasn't explicit, but I'm not looking for alternative implementations that work. I know there are lots of other ways to lay this out and BoxSizers are the old workhorse on things like this.
I'm trying to track down what I believe is a longstanding bug in GridBagSizer and I finally found what appears to be a fairly simple test case that shows it.
In an older version I tried reversing the order of Adding things to the GBS but it didn't seem to change anything. But even so that would seem like a bug once the case of removing/adding controls dynamically is considered.
The particular version you attached doesn't really do what I want as the text controls don't span the whole width.
Thanks,
Michael
···
On 11/7/2011 7:58 AM, werner wrote:
On 11/07/2011 02:09 PM, Michael Hipp wrote:
I'm trying to track down what I believe is a longstanding bug in GridBagSizer
and I finally found what appears to be a fairly simple test case that shows it.If that is your goal then try this one.
I don't recall but I believe that GBS has some rule that influences column size
based on what you add first, i.e. in attached I am adding the long static text
down to after the html/text controls.
The first one (htmlsizerissue.py) still has the text controls sized differently, tho oddly it is now the rightmost one that is too small. Weird.
The second one (htmlsizerissue2.py) makes use of BoxSizer & FlexGridSizer and certainly works. But understand this is a *greatly* simplified sample app of a complex panel where I really want/need to use a GBS. The "spanning" feature of the GBS is the killer app.
But what I really want to do is either determine there's a bug in GBS or find out what I've been doing wrong these last 5 years. I'm open to either conclusion.
Thanks for your time and attention, werner.
Michael
···
On 11/7/2011 7:47 AM, werner wrote:
On 11/07/2011 02:16 PM, Michael Hipp wrote:
On 11/6/2011 12:02 PM, Michael Hipp wrote:
Can someone show me what I'm doing wrong in the attached sample program? The
two html windows are supposed to be the same size. Also attached a screenshot.I've reduced it to a yet simpler app that shows the problem. Oddly the sizing
changes somewhat on TextCtrls instead of HtmlWindows but is still wrong.
Please see attached sample app and screenshot.See attached, changed the span of things for the gbs, but I would probably do
it like in the second one.
What I did:
- Set MinSize of label to (1, -1)
- Expand the sizer item for the label
- Center the text on the level of the label via it's style
It seems to work, what do you think?
Toni
sizers5_fixed.py (1.32 KB)
···
On Mon, 07 Nov 2011 14:16:09 +0100, Michael Hipp <michael@redmule.com> wrote:
On 11/6/2011 12:02 PM, Michael Hipp wrote:
Can someone show me what I'm doing wrong in the attached sample program? The
two html windows are supposed to be the same size. Also attached a screenshot.I've reduced it to a yet simpler app that shows the problem. Oddly the sizing
changes somewhat on TextCtrls instead of HtmlWindows but is still wrong. Please
see attached sample app and screenshot.Win7, Py2.7.2, WxPy 2.9.2.4
Interestingly I get the same on a similar configuration BUT on the older
system WinXP, Python 2.5.4, wxPython 2.8.10.1 Unicode - the proportion
are OK unless you shrink the window beyond a given point when the
leftmost jumps to a smaller proportion then sits there while the
rightmost is able to shrink to zero.
Gadget/Steve
···
On 07/11/2011 1:16 PM, Michael Hipp wrote:
On 11/6/2011 12:02 PM, Michael Hipp wrote:
Can someone show me what I'm doing wrong in the attached sample
program? The
two html windows are supposed to be the same size. Also attached a
screenshot.I've reduced it to a yet simpler app that shows the problem. Oddly the
sizing changes somewhat on TextCtrls instead of HtmlWindows but is
still wrong. Please see attached sample app and screenshot.Win7, Py2.7.2, WxPy 2.9.2.4
Thanks,
Michael
Hi Michael,
But what I really want to do is either determine there's a bug in GBS or find out what I've been doing wrong these last 5 years. I'm open to either conclusion.
Yes, GBS has some nice things but it is also a ............. to work with.
Are you aware of this wiki page:
http://wiki.wxpython.org/wxGridBagSizer
Werner
Yes, that does seem to work. But 2 things:
- It won't work for my original sample or my actual problem as I don't want to have to put wx.EXPAND on that label line. My original problem has a static box there which I don't want to blow up to screen width.
- Requiring setting that odd MinSize() seems rather hackish and shouldn't be necessary. That's what sizers are for, to figure out sizes.
Thanks,
Michael
···
On 11/7/2011 9:21 AM, Toni Ruža wrote:
On Mon, 07 Nov 2011 14:16:09 +0100, Michael Hipp <michael@redmule.com> wrote:
What I did:
- Set MinSize of label to (1, -1)
- Expand the sizer item for the label
- Center the text on the level of the label via it's styleIt seems to work, what do you think?
I was not aware of it, thanks.
I think the problem I'm bumping against is related to the explanations on that page. It seems to me that the 3rd diagram ("tricky thing") is explaining that it takes its sizing cues from the wrong thing. The second row should be sized from the first only insofar as to make sure there is room for the first row. As explained, the second row is set too large for the contents of either.
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.
Thanks,
Michael
···
On 11/7/2011 9:40 AM, werner wrote:
Are you aware of this wiki page:
http://wiki.wxpython.org/wxGridBagSizer
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, but it fits the symptoms (and just setting the proportions to 1 does work in 2.8 the way I thought it would).
With that in mind I think a good a good workaround for your case would be to use CalcMin on your StaticBoxSizer in the first row to get the desired space for that item, and then set the minsize width for each of the items in the 2nd row to be 1/2 that width.
···
On 11/7/11 9:38 AM, Michael Hipp wrote:
On 11/7/2011 9:21 AM, Toni Ruža wrote:
On Mon, 07 Nov 2011 14:16:09 +0100, Michael Hipp <michael@redmule.com> >> wrote:
What I did:
- Set MinSize of label to (1, -1)
- Expand the sizer item for the label
- Center the text on the level of the label via it's styleIt seems to work, what do you think?
Yes, that does seem to work. But 2 things:
- It won't work for my original sample or my actual problem as I don't
want to have to put wx.EXPAND on that label line. My original problem
has a static box there which I don't want to blow up to screen width.- Requiring setting that odd MinSize() seems rather hackish and
shouldn't be necessary. That's what sizers are for, to figure out sizes.
--
Robin Dunn
Software Craftsman
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?
> (and just setting the proportions to 1 does work in
> 2.8 the way I thought it would).
Yes, but note that the docs say otherwise: wxPython API Documentation — wxPython Phoenix 4.2.2 documentation
With that in mind I think a good a good workaround for your case would be to
use CalcMin on your StaticBoxSizer in the first row to get the desired space
for that item, and then set the minsize width for each of the items in the 2nd
row to be 1/2 that width.
Thanks. This seems like it ought not be necessary and would be very brittle to any future changes in the layout or composition of the panel.
Methinks my solution will be to get over the mental-block inelegance of N-Layer BoxSizers "all the way down". I seem to have a case of GBS fatigue.
Thanks,
Michael
···
On 11/7/2011 1:32 PM, Robin Dunn wrote:
Yes, go ahead and make a ticket for it. Set the component to GUI-all and put wxGridBagSizer in the keywords.
···
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?
--
Robin Dunn
Software Craftsman