Opened 9 years ago

Last modified 8 years ago

#14498 confirmed enhancement

Forbid changing vertical size of comboboxes and single line text controls

Reported by: osvenskan Owned by:
Priority: low Milestone:
Component: GUI-all Version:
Keywords: wxComboBox vertical size Cc:
Blocked By: #11497, #11497, #11497, #11497, #11497, #11497 Blocking:
Patch: no

Description

Under wx 2.8, comboboxes with WX_EXPAND set will expand horizontally but not vertically. Under wxPython 2.9.3.1, they expand both horizontally and vertically. The 2.9 behavior looks bad and even prompts a warning from the OS X Cocoa library which appears in the console window where I started Python. The warning reads something like this:

2012-07-19 14:09:48.814 Python[35316:60f] This application is trying to draw a very large combo box, 28 points tall.  Vertically resizable combo boxes are not supported, but it happens that 10.4 and previous drew something that looked kind of sort of okay.  The art in 10.5 does not break up in a way that supports that drawing.  To avoid breaking existing apps, NSComboBox in 10.5 will use the 10.4 art for large combo boxes, but it won't exactly match the rest of the system.  This application should be revised to stop using large combo boxes.  This warning will appear once per app launch.

The solution is pretty simple (I hope!) -- don't expand comboboxes vertically.

I have attached an app that demonstrates the problem. Start it and resize the frame to make it larger. The attached screenshot wx2.8.12.0.png shows what this look like under wxPython 2.8.12.0, and the screenshot wx2.9.3.1.png shows what this look like under wxPython 2.9.3.1.

Attachments (5)

wx2.8.12.0.png download (13.5 KB) - added by osvenskan 9 years ago.
wx2.9.3.1.png download (51.0 KB) - added by osvenskan 9 years ago.
se_gui.py download (1.4 KB) - added by osvenskan 9 years ago.
wx.2.9.3.1-windows.png download (12.5 KB) - added by osvenskan 8 years ago.
se_gui2.py download (1.5 KB) - added by osvenskan 8 years ago.

Download all attachments as: .zip

Change History (15)

Changed 9 years ago by osvenskan

Changed 9 years ago by osvenskan

Changed 9 years ago by osvenskan

comment:1 Changed 8 years ago by vadz

  • Keywords wxComboBox size added
  • Priority changed from normal to lowest

I think vertically expanded comboboxes don't look good under any platform so it's not a good idea to do this anywhere and I don't see why would you want to do it anyhow. Simply don't expand them (in vertical direction) in your layout, what is the problem?

comment:2 Changed 8 years ago by osvenskan

I agree, I don't think it looks good and I don't want them to expand vertically. I think everyone would agree on that, which is (I assume) why wx2.8 doesn't expand them vertically using the sample code provided. wx2.9, on the other hand, does.

Note that the controls in question are in a grid sizer, so it's not like a box sizer where I can set the orientation to horizontal or vertical. I guess I could wrap the contents of each grid sizer cell in a box sizer, but I wonder why I didn't have to do that under wx2.8.

comment:3 Changed 8 years ago by vadz

  • Priority changed from lowest to low
  • Status changed from new to confirmed
  • Summary changed from OS X Cocoa - comboboxes expand vertically to Forbid changing vertical size of comboboxes and single line text controls
  • Type changed from defect to enhancement

I think comboboxes would still expand even in 2.8 in wxGTK. Also, combobox is not the only control it doesn't make sense to expand vertically, single line text control falls into the same category. If we really want to forbid changing the vertical combobox size, we should presumably do the same for single line text controls. And do it in all ports.

As for using them in 2D sizers: yes, you need to put the cell contents in a box sizer to make this work correctly.

comment:4 Changed 8 years ago by osvenskan

  • Component changed from wxOSX-Cocoa to GUI-all
  • Keywords vertical added

comboboxes would still expand even in 2.8 in wxGTK.

You are correct. I have never noticed this, even though we test our apps under OS X, Windows & GTK.

combobox is not the only control it doesn't make sense to expand
vertically, single line text control falls into the same category

I agree with that and the rest of your comment.

FYI, this behavior is inconsistent across platforms. I added a single line textbox to the grid sizer on the same row as the comboboxes (in attachment se_gui2.py) and here's what I see when I expand the frame --

OS X/wx2.8 - textbox grows vertically, comboboxes do not
OS X/wx2.9 - all grow vertically
Windows/wx2.8 - textbox grows vertically, comboboxes do not
Windows/wx2.9 - textbox grows vertically, comboboxes grow to a certain height (about 10 ems) but no more after that. See wx.2.9.3.1-windows.png.
GTK/wx.28 - all grow vertically
GTK/wx.29 - not tested

So, my initial problem report was correct but definitely misleading. Thanks for helping me to the big picture.

IMHO the problem with the big picture is inconsistency. The current state of affairs is only discoverable through trial and error, and that's not desirable. One resolution would be to have all controls in a grid sizer grow vertically unless they're constrained by a box sizer. It's probably not the most commonly desired behavior, but at least it would force developers to realize that they need to actively control vertical growth in grid sizers.

Changed 8 years ago by osvenskan

Changed 8 years ago by osvenskan

comment:5 Changed 8 years ago by vadz

  • Blocked By 11497 added

I think the best way to solve this inconsistency would indeed be to set the max vertical size for these controls by default. Unfortunately, currently this wouldn't work because of #11497. But once it's fixed, this should be simple enough to do.

comment:6 Changed 8 years ago by HighCommander4

  • Blocked By

comment:7 Changed 8 years ago by VZ

  • Blocked By

(In #11497) (In [72343]) Honour window min and max sizes in wxWindow::GetBestSize().

The best size of the window should be at least as large as its min size and
less than its max size. This allows to override the windows own best size
determination with an explicit SetMinSize() or SetMaxSize() call.

See #11497.

comment:8 Changed 8 years ago by VZ

  • Blocked By

(In #11497) (In [72344]) No real changes, just add wxSizerItem::AddBorderToSize() helper.

Factor out this function from GetMinSizeWithBorder() as it will be used for
max size too in a next commit.

See #11497.

comment:9 Changed 8 years ago by VZ

  • Blocked By

(In #11497) (In [72345]) Respect item max sizes in wxBoxSizer.

Don't give more space than the max size, if set, to wxBoxSizer elements.

Closes #11497.

comment:10 Changed 8 years ago by VZ

  • Blocked By

(In #11497) (In [72586]) Fix handling of not fully specified min/max size in wxBoxSizer.

wxSizerItem::AddBorderToSize() added in r72344 (see #11497) didn't work
correctly as it replaced unspecified (i.e. set to -1) components of wxSize
with the small positive values that did take effect, contrary to the
intention.

Fix it to only adjust the actually set component(s) of wxSize.

Closes #14696.

Note: See TracTickets for help on using tickets.