Micromounts

July 25, 2024

Python micromount database -- wxpython

I could use gtk3 I suppose, or perhaps some other GUI toolkit, but I have some experience with wxPython. It has served me well, it is multiplatform, so why not? The big 3 are Qt, GTK, and Wx. If you want to develop from C, GTK is the only real option. From Python, anything is possible.

The above tutorials seem pretty good. The name of the game right now is to get back up to speed, and perhaps deepen my understanding as part of the process.

It is important to remember that "Wx" is actually a C++ widget set that we use Python bindings to access. This means that the Wx documentation can be of great use to understand both details and high level concepts.

Wx Widgets

Note that it is more or less impossible to use Wx directly from C, you will need to work from C++ (something I am unwilling to do).

Tips

I found these online in responses to people frustrated with skimpy WxPython documents.

Don't be afraid to look at the C++ API documentation
Forget menu stuff at the start, you can add it later.
Learn the differences between: wxWindow, wxScrolledWindow, wxFrame, wxPanel.
Learn dialogs: wxMessageDialog, wxTextEntryDialog, wxSingleChoiceDialog, wxMultipleChoiceDialog.
Avoid sizers, use RolColSizer, especially to get started.
wxGrid is golden and well worth time to study
Write your own methods to wrap wx API calls.

Apps, Windows, Frames, Panels, and Dialogs

An application does not necessarily have any realization on the screen. What goes on the screen are Frames or Dialogs. The application runs the mainloop and a toplevel "window" can be specified and that is pretty much it.

A "window" per se, never shows up in the API. It is a root class for almost everything else, but you shouldn't care about that. So forget about windows -- or at least forget about looking for them in the API.

The main window of a typical application is a "Frame" object. This is something a system window manager will manage. Perhaps an application could have several frames, but this would be unusual.

The business of Panels seems to be a major area of confusion (i.e. poor documentation). A Panel is intended as a container to hold widgets. A Frame will typically hold one or more panels. You should not place widgets directly into a frame (why?) but should put them into a panel. And if you segment a GUI into several panels, you should set up one big container panel to hold the smaller panels. Why? Nobody knows. But this is what you should do.
Use lots of panels, panels within panels, hierarchies of panels.

Dialogs are generally "modal". This means that they appear and grab focus until dismissed.

Sizers

Despite the advice to ignore these initially, I find these essential. A sizer is not something that should be thought of as a widget or a thing that appears on a screen. It is generally (the way I use them) hooked onto a panel and instructed to manage objects that are placed into the panel. Every time I start to use one, I get an error like this:

Windows managed by the sizer associated with the given window must have this window as parent,
otherwise they will not be repositioned correctly.
Please use the window wxFrame@0x558bdc048470 ("One mount") with which this sizer is associated,
as the parent when creating the window wxControl

Since I fall into this hole each and every time, I figure it is worth documenting what I am doing wrong so I can refer back here the next time I find myself in this hole.

In the above case I have a panel within a frame. The fix was to change the first line below to the second.

self.SetSizer ( s )
pan.SetSizer ( s )

The first line was setting the sizer to the frame, but I wanted it set to the panel within that frame.

Feedback? Questions? Drop me a line!

Tom's Mineralogy Info / tom@mmto.org