Extremely long lines: feature or bug?

wxPython Users
1

A.J. Bonnema wrote:

What happens here, is that the option sizer gets expanded to well beyond the window's borders, because the previous sizer is expanded because of the weights. I suspect, that a factor of 50 means, that -- whatever the window size -- the label will be extended to be 50 times the minimum length of the field on the same sizer. Unless the field has factor zero, in which case there is no reference for the label to expand.

What bugs me, is that wx.EXPAND and weights can get *way* beyond the window width. You could argue that a ratio of 50 to 1 is bullocks and the function works as designed, but you also argue that the sum of the lengths should never exceed the window itself.

So, I am left wondering: is this a feature or a bug?

It's a feature. The sizers are designed to allow items to be larger than the window size, in order to accommodate situations where scrolled windows are used for the container, or when the user needs to make the window smaller to see something else. There is no way to tell the sizer to shrink a fixed size item or an item with a minsize when there is not space enough to show them all, which is what would be necessary to be able to do what you suggest, and then fixed size or minsize would not have much meaning any more.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

2

Robin Dunn wrote:

A.J. Bonnema wrote:

What happens here, is that the option sizer gets expanded to well beyond the window's borders, because the previous sizer is expanded because of the weights. I suspect, that a factor of 50 means, that -- whatever the window size -- the label will be extended to be 50 times the minimum length of the field on the same sizer. Unless the field has factor zero, in which case there is no reference for the label to expand.

What bugs me, is that wx.EXPAND and weights can get *way* beyond the window width. You could argue that a ratio of 50 to 1 is bullocks and the function works as designed, but you also argue that the sum of the lengths should never exceed the window itself.

So, I am left wondering: is this a feature or a bug?

It's a feature. The sizers are designed to allow items to be larger than the window size, in order to accommodate situations where scrolled windows are used for the container, or when the user needs to make the window smaller to see something else. There is no way to tell the sizer to shrink a fixed size item or an item with a minsize when there is not space enough to show them all, which is what would be necessary to be able to do what you suggest, and then fixed size or minsize would not have much meaning any more.

This is not exactly what I meant. I can understand that minimum size is minimum size. Having enough minimum size *will* extend beyond the window, which makes sense. I will explain what I meant.

The point here is the variable space controlled by wx.EXPAND. The sample program I added has a few boxes of which one box with wx.HORIZONTAL that contains two items:

1. An textctrl item with a fixed width of for instance 5 characters (more or less) and a weight of 1.
2. An label item without a fixed width, but the option wx.EXPAND and a large weight, for instance 50.

The weight of the variable label versus the textctrl determines the width of the sizer, irrespective of window width. The next sizer will also be as wide as this sizer.

The point is, that even though the label does not *have* a minimum size, the label will be made to have the width of 50 times the width of the first item (textctrl), spanning a lot more space than the window has.

I would have expected the weight to divide the available space among items. I.e. if the fixed item has a length of 5 units, and there are 80 units available, that the ex.EXPAND item would get the remaining 75 units alotted, even though 50 times 5 is a lot more.

What happens here, is that the window size is ignored, making the one minimum size available of 5 units determine the width of the other units and the sizer and all next horizontal sizers, through the weights.

Obviously, if this was a conscious design decision, I have no intention of overturning it as I have not contributed to wxPython: I only just started with wxPython.

I was just wondering whether this was a conscious design decision, or maybe a bug.

Guus.

···

--
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)

3

Robin Dunn wrote:

A.J. Bonnema wrote:

I was just wondering whether this was a conscious design decision, or maybe a bug.

Probably neither. I would consider it more of a side-effect of how the implementation was done.

Fair enough.

BTW, when I was playing with your sample the other day I found one problem, and correcting it does make the layout act more like you are probably expecting. The upper panel was being made a child of the frame, but was added to the other panel's sizer. If you make the upper panel a child of the main panel instead, and don't worry about Fit or SetSizeHints, (because the layout will be sized and constrained by the limits of the frame anyway,) then things work much better. See the attached.

Thank you very much. I will check it out!

Guus.

···

--
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)

4

Robin Dunn wrote:

BTW, when I was playing with your sample the other day I found one problem, and correcting it does make the layout act more like you are probably expecting.

Oh, and thanks for the inspection tool: very handy!
(I probably missed that in the book). For the interested, include:

import wx.lib.inspection
wx.lib.inspection.InspectionTool().Show()

and your program will start with a tool that shows all the GUI bits and pieces.

Guus.

···

--
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)