GUI Design (Code) Question

So I’m fiddling around with an app, and it occurred to me that I’m missing out on something. Okay, I miss out on stuff all of the time, but bear with me.

If I have an application with the following UI:

What is considered the best practice for this UI?

  1. Embed two side-by-side panels in the wxFrame
  2. Put another panel on the wxFrame and embed the two panels on it
  3. Subclass wx.Panel and embed all of the controls on it using sizers to control placement

I’ve got a version of each because I’m learning/experimenting, but my thoughts are:

  1. May be overkill when #3 may suffice.
  2. Seems like this would use additional system resources unnecessarily.
  3. BFFI version. :joy:

I’m going to be teaching my son and some of his mates how to design GUIs this summer and wxPython is sort of my preferred toolkit soooooo…

All thoughts, comments, etc. are welcome!

Why make things complicated with a lot of panels?

  • A frame with a panel. Then a horizontal box sizer for left/right.
  • A vertical box sizer for the texts and headings at the left.
  • A vertical box sizer for the right half. A horizontal box sizer for the three buttons.

Depending on the required re-sizing behaviour, a grid sizer with a single column might be required for the left half (to distribute the controls over the full height).
For the right half, a static box sizer (i.e. with a label) might be applicable.

ChuckM.py (4.1 KB)
ChuckM.zip (1.2 KB)

To quote myself from http://wxglade.sourceforge.net/docs/wxbasics.html :

  • For your own projects, always use the simplest available sizers. Usually you will need mainly box sizers and maybe one or two FlexGridSizers.
  • Use nested sizers to match the hierarchical / logical structure of your project. This will make it easy to re-arrange things to find the best user interface.
  • Never ever try to use a GridBagSizer as main sizer of a window trying to resemble pixel placement or Tkinter’s grid geometry manager. This is a mess to create and maintain. Actually, a GridBagSizer is almost never needed.

Hi.

I do agree with DietmarSchwertberfer : no needs of multiple panels for such an interface.
And the method he describes will facilitate yourself if you have (for example) to fill the textboxes when selecting an entry in the list on the right.

Regards
Xav’

Thanks for your response. That’s the approach I’ve taken on a personal project, but I’ve been away from wxWidgets/wxPython for a while and as I’m just getting back into the swing I like to know what the current set of best practices are from people who are working with the toolkit every day.

The other side of the coin is that sometimes it does make sense to use the extra panels. It’s really not enough overhead to matter, for a reasonable number of widgets anyway. For example, if some group of widgets are a self-contained concept, then encapsulating all the UI and at least some of the behavior into a single class derived from wx.Panel makes sense. It really depends on what makes the most sense to you, and how you prefer to organize things.

trying to generate a GUI it’s obvious to fall back to the minimum: h & v boxes are the bare bones (after the panel); but what the user scribbles usually resembles what the GridBag wants to provide! so coming from the application side one wouldn’t dream of less than a GridBag (per panel): after all most screens are still squarish filled with some controls here & there…

I have a question, why the use of a panel anyway, at least in this kind of examples?
I would like to know what its advantage is. wxGlade by default adds a Panel with a Sizer to the frame (unless you uncheck that option, but I get the impression that you can as well add the Sizer directly to the Frame. Is there a disadvantage to doing this?
For example, I took the ChuckM example above and removed the Panel end sizer_1, and it gives the same UI.

On some platforms, I think mainly Windows, the panel is responsible for the navigation through the controls. Without the panel you can’t navigate through the controls with Tab and Shift+Tab.

Also on Windows the background colour of the plain frame will look darker than usual.

(The release versions of wxGlade also require a sizer between the frame and the panel. This has changed in the master branch already.)

2 Likes

it was too tempting…ChuckM - Copy.py (2.6 KB)

Nice, I haven’t played with the GridSizer yet although I will likely get to it in a later iteration.

I’m currently focused on the widgets to work the way I need them to. At this current point in the project, I want to keep things somewhat simple so that I can see what’s going on, but I know from experience that I will continue to iterate to find better ways to do what I’m doing. :grin:

I’m a big fan of using wxGlade to keep my GUI development separate from the rest of the project. And I find that I can do most things within wxGlade with only a smattering of hand wrapping when I want to be really fancy.

That said, I find that having widgets grouped in a Panel lets me Hide the panel/widgets later (if I want to make those controls unavailable for some reason). Just my 2 cents.

1 Like

I like using a Dialog window for windows that look like that so that it can stand alone as an app, or be reused later as part of a larger project, if appropriate.

app.py (578 Bytes) chuckm_dialog.zip (2.4 KB) MyDialog.py (3.5 KB)

another Roman outing…
ChuckM - Copy.py (2.6 KB)
and I can assure you the most interesting quarters (listview on this trip) we haven’t been yet…

You can also use wxFormBuilder to quickly construct your UI design.

the window was crying out lout for a split…
ChuckM_split.py (2.7 KB)