now I feel responsible ;-)
> I can also find api reference
> documentation which tells me that a given wx Python class is
> a proxy for some C++ class
That's pretty much how all of wx is built -- it's an implementation
detail you can usually ignore.
> or tells me that Create "Create[s]
> the GUI part of the Window for 2-phase creation mode" (what
> the hell is "2-phase creation mode?"), e.g.:
>
> http://www.wxpython.org/docs/api/wx.Panel-class.html
rarely needed. Usually you just subclass and instantiate your subclass
where you need it.
> I have not yet been able to find a bit of documentation which
> tells me (for example) how a Panel differs from a Frame.
If that's not in the Wiki, it really should be -- it has been
asked/discussed all too many times on this list!
You have found the Wiki, haven't you?
> Using my monkey-see-monkey-do approach I have built a mess
> which seems marginally functional, but which I can tell is
> going to be difficult to maintain as it grows.
Do look at the Wiki pages on MVC/MVP for some (not-wxPython-specific)
ideas about app structure.
> Maybe there's some better way? Is there a wx-for-(gtk|tk)
> programmers document somewhere?
I don't know, but there probably should be -- maybe you could start a
Wiki page on that. I personally started with little GUI experience, so
I'm not sure what the stumbling blocks are for folks with Tk or GTK
experience.
> Pointers/tips/rants cheerfully accepted.
1) A wx.Window is the basic building block of everything wx --
essentially a rectangle on the screen. It is the subclass of most
controls, Panels, Dialogs, Frames.
A wx.Frame is a "top-level Window" -- one that the System/Window manager
manages, puts decorations on, etc.
A wx.Dialog is also a top-level Windows, but designed to be, well, a
dialog, so is handles a bit differently, can be set modal, and usually
has a Frame as a parent.
A wx.Panel is a wx.Window designed to put other Windows/controls on --
it provides some extra features like tab traversal, etc.
This is covered in this tutorial, too:
http://wiki.wxpython.org/AnotherTutorial
2) "wxPython in Action" is the best (only) place to get it all in one
well organized place. (though you can find most of what you need in the
docs, Wiki, list archives, various blogs, etc)
3) Read the topic guides in the wx docs:
http://www.wxpython.org/onlinedocs.php
mostly written for C++, but lots of good stuff there.
4) read the Style Guide:
http://wiki.wxpython.org/wxPython%20Style%20Guide
5) read other stuff in the Wiki -- it's not all that well organized, but
there is good stuff there.
6) It sounds like you've found the Demo -- do keep going back to it,
there is an incredible amount of good stuff there.
7) Keep the questions coming here -- this is a great community.
Welcome!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Hi Skip, it's nice to see you here.
> having been nudged in that direction by
> Chris Barker on account of a Tkinter app on my Mac which doesn't
> play real well with matplotlib's MacOSX backend. Wx seems to
> do much better in that regard. However...
>
> I seem to be able to find lots of examples which provide me
> with a monkey-see-monkey-do way of building applications but
> provide little or no basis for understanding the principles
> underlying the stuff I'm using.
There is a good tutorial here: http://zetcode.com/wxpython/, there is
the book: http://wiki.wxpython.org/wxPythonInAction, and lots of random
tidbits in the wiki: http://wiki.wxPython.org/
> I can also find api reference
> documentation which tells me that a given wx Python class is
> a proxy for some C++ class or tells me that Create "Create[s]
> the GUI part of the Window for 2-phase creation mode"
> (what
> the hell is "2-phase creation mode?"), e.g.:
It is a way to split the creation of the widget into two steps.
Essentially it allows you to create the instance of the class first, and
then call the Create method to actually create the UI object. This has
more utility in C++ than in Python so we don't really use it very much,
but it can be used to do things like setting extra flags, causing the
widget to be hidden when it is created instead of shown, or other
non-standard things that need to be done before the UI widget is
created. It is also used in the XRC framework where XRC will allow you
to do things like instanciate a custom class that it knows nothing
about, and then later when it has read all the properties from the xml
steam it will call Create for you, hook the widget into the specified
sizers, etc.
>
> http://www.wxpython.org/docs/api/wx.Panel-class.html
>
> I have not yet been able to find a bit of documentation which
> tells me (for example) how a Panel differs from a Frame.
In a nutshell the Frame is the thing on screen that most people would
typically call a window[1]. It has the window caption and resize
handle(s) allowing the user to move and resize the window, can have a
menu bar, status bar, tool bar, and can contain other widgets. The
frame is considered a "Top Level Window" because it can exist without a
parent, or you might think of it as having the desktop as its parent by
default.
A Panel on the other hand is not a TLW and so it must always be given a
parent when it is created. It is typically used as a container window
to hold other widgets, and it implements tab-traversal between those
widgets, and can also participate in tab traversal between sibling
panels or with parent containers if it is in that kind of context.
Usually simple apps will have a frame, possibly with one or more of the
(menu|tool|status)bars, and will have a panel as its only other child.
In that panel will reside the other widgets implementing your
application's UI. Since this scenario is so common the Frame has a
default feature where if it has only one child (besides the bars) then
it will automatically resize that child to fill the client area of the
frame.
> Maybe there's some better way? Is there a wx-for-(gtk|tk)
> programmers document somewhere?
Not that I know of[2], but it would be a good addition to the wiki. If
you take some notes as you're learning about things that tripped you up
or that seemed strange or difficult from a (gtk|tk) perspective then
that could serve as the basic outline for such a document.
[1] From a programming point of view you can think of nearly every
independent rectangle on screen as being a window. Frames, panels,
buttons, listboxes, etc. are all windows and share common traits,
methods, etc. In wx this is represented by the wx.Window base class.
[2] There are some "wxPython vs tkinter" pages out there that google
will turn up, but I think that they are all "pros and cons" types of
documents rather than "How to change your GUI brain" types.
--
Robin Dunn
Software Craftsman
http://wxPython.org
> to do things like instanciate a custom class that it knows nothing
> about, and then later when it has read all the properties from the xml
> steam it will call Create for you, hook the widget into the specified
That should be "stream". You'd think that by now spell checkers would
be able to read my mind and know what I really wanted to write...
Good serious answers have been provided. I have no idea
what inspired the following different take on an answer, though I
suspect something in the Belgian dark chocolate I had
after lunch is related. (note: "Vippi" is the wxPython mascot,
a goofy green python)...
The Difference Between a Frame and a Panel
One's a panel, one's a frame.
But these two are not the same.
A frame is just an outermost
rectangle you use to host
the denizens of Widgetry,
whatever those things are to be.
A frame will have a title bar,
min/max boxes, and at far
upper right, a close box, too,
just like Word or Notepad do:
what laymen call a "window", see?
(though Vippi may just disagree.
He feels "window" means a widget,
though that use is not too rigid;
oft times just "control" is used.
Jargon keeps a snake amused).
But go without a frame? Unsound!
How will you move your app around?
A panel, though, is just a place,
*within* a frame that takes up space,
Inside of each you'll surely cordon,
groups of widgets that you're hoardin'.
A panel's almost necessary
since bare frames are pretty scary
and create most widgets' terror;
do this and you risk an "error".
Panels, though, will do just fine,
I put one first on frames of mine.
The first expands out to the border
of the frame, by Vippi's order.
(or a "book" control will do,
and will expand this way for you).
Panels can be writ alone,
but can't get by just on their own.
They need containers like a frame,
(or a dialog) to name
as their "parent"--where they go--
so that when its frame you .Show(),
the panel(s) will be shown to you
(with all the widget children, too),
as a region(s) in your frame.
And that's enough to try the game.