Every wxPython app is an instance of wx.App. For most simple applications you can use wx.App as is. When you get to more complex applications you may need to extend the wx.App class. The "False" parameter means "don't redirect stdout and stderr to a window".

wx.Frame(None,wx.ID_ANY,"Hello")

A wx.Frame is a top-level window. The syntax is x.Frame(Parent, Id, Title). Most of the constructors have this shape (a parent object, followed by an Id). In this example, we use None for "no parent" and wx.ID_ANY to have wxWidgets pick an id for us.

frame.Show(True)

We make a frame visible by "showing" it.

app.MainLoop()

Finally, we start the application's MainLoop whose role is to handle the events.

Note: You almost always want to use wx.ID_ANY or another standard ID (v2.8) provided by wxWidgets. You can make your own IDs, but there is no reason to do that.

Run the program and you should see a window like this one:

Windows or Frames?

When people talk about GUIs, they usually speak of windows, menus and icons. Naturally then, you would expect that wx.Window should represent a window on the screen. Unfortunately, this is not the case. A wx.Window is the base class from which all visual elements are derived (buttons, menus, etc) and what we normally think of as a program window is a wx.Frame. This is an unfortunate inconsistency that has led to much confusion for new users.

Building a simple text editor

In this tutorial we are going to build a simple text editor. In the process, we will explore several widgets, and learn about features such as events and callbacks.

First steps

The first step is to make a simple frame with an editable text box inside. A text box is made with the wx.TextCtrl widget. By default, a text box is a single-line field, but the wx.TE_MULTILINE parameter allows you to enter multiple lines of text.

In this example, we derive from wx.Frame and overwrite its __init__ method. Here we declare a new wx.TextCtrl which is a simple text edit control. Note that since the MyFrame runs self.Show() inside its __init__ method, we no longer have to call frame.Show() explicitly.

Adding a menu bar

Every application should have a menu bar and a status bar. Let's add them to ours:

TIP: Notice the wx.ID_ABOUT and wx.ID_EXIT ids. These are standard ids provided by wxWidgets (see a full list here). It is a good habit to use the standard ID if there is one available. This helps wxWidgets know how to display the widget in each platform to make it look more native.

Event handling

Reacting to events in wxPython is called event handling. An event is when "something" happens on your application (a button click, text input, mouse movement, etc). Much of GUI programming consists of responding to events. You bind an object to an event using the Bind() method:

This means that, from now on, when the user selects the "About" menu item, the method self.OnAbout will be executed. wx.EVT_MENU is the "select menu item" event. wxWidgets understands many other events (see the full list). The self.OnAbout method has the general declaration:

Here event is an instance of a subclass of wx.Event. For example, a button-click event - wx.EVT_BUTTON - is a subclass of wx.Event.

The method is executed when the event occurs. By default, this method will handle the event and the event will stop after the callback finishes. However, you can "skip" an event with event.Skip(). This causes the event to go through the hierarchy of event handlers. For example:

When a button-click event occurs, the method OnButtonClick gets called. If some_condition is true, we do_something() otherwise we let the event be handled by the more general event handler. Now let's have a look at our application:

Dialogs

Of course an editor is useless if it is not able to save or open documents. That's where Common dialogs come in. Common dialogs are those offered by the underlying platform so that your application will look exactly like a native application. Here is the implementation of the OnOpen method in MainWindow:

Then, we call ShowModal. That opens the dialog - "Modal" means that the user cannot do anything on the application until he clicks OK or Cancel.

The return value of ShowModal is the Id of the button pressed. If the user pressed OK we read the file.

You should now be able to add the corresponding entry into the menu and connect it to the OnOpen method. If you have trouble, scroll down to the appendix for the full source code.

Possible extensions

Of course, this program is far from being a decent editor. But adding other features should not be any more difficult than what has already been done. You might take inspiration from the demos that are bundled with wxPython:

Working with Windows

Topics:

Frames

Windows

Controls/Widgets

Sizers

Validators

In this section, we are going to present the way wxPython deals with windows and their contents, including building input forms and using various widgets/controls. We are going to build a small application that calculates the price of a quote. If you are already an experienced GUI developer, this is going to be easy and you might want to move on to the Boa-Constructor Subsection in the Advanced topics chapter.

Overview

Laying out Visual Elements

Within a frame, you'll use a number of wxWindow sub-classes to flesh out the frame's contents. Here are some of the more common elements you might want to put in your frame:

A wx.MenuBar, which puts a menu bar along the top of your frame.

A wx.StatusBar, which sets up an area along the bottom of your frame for displaying status messages, etc.

A wx.Panel, which is a container to hold your various wx.Control objects. Putting your wx.Control objects inside a wx.Panel means that the user can tab from one UI widget to the next.

All visual elements (wxWindow objects and their subclasses) can hold sub-elements. Thus, for example, a wx.Frame might hold a number of wx.Panel objects, which in turn hold a number of wx.Button, wx.StaticText and wx.TextCtrl objects, giving you an entire hierarchy of elements: Note that this merely describes the way that certain visual elements are interrelated -- not how they are visually laid out within the frame. To handle the layout of elements within a frame, you have several options:

You can manually position each element by specifying it's exact pixel coordinate within the parent window. Because of differences in font sizes, etc, between platforms, this option is not generally recommended.

You can use wx.LayoutConstraints, though these are fairly complex to use.

You can use the Delphi-like LayoutAnchors, which make it easier to use wx.LayoutConstraints.

You can use one of the wxSizer subclasses.

This document will concentrate on the use of wxSizers, because that's the scheme I'm most familiar with.

Sizers

A sizer (that is, one of the wx.Sizer sub-classes) can be used to handle the visual arrangement of elements within a window or frame. Sizers can:

Calculate an appropriate size for each visual element.

Position the elements according to certain rules.

Dynamically resize and/or reposition elements when a frame is resized.

Some of the more common types of sizers include:

wx.BoxSizer, which arranges visual elements in a line going either horizontally or vertically.

wx.GridSizer, which lays visual elements out into a grid-like structure.

wx.FlexGridSizer, which is similar to a wx.GridSizer except that it allow for more flexibility in laying out visual elements.

A sizer is given a list of wx.Window objects to size, either by calling sizer.Add(window, options...), or by calling sizer.AddMany(...). A sizer will only work on those elements which it has been given. Sizers can be nested. That is, you can add one sizer to another sizer, for example to have two rows of buttons (each laid out by a horizontal wx.BoxSizer) contained within another wx.BoxSizer which places the rows of buttons one above the other, like this:

Note: Notice that the above example does not lay out the six buttons into two rows of three columns each -- to do that, you should use a wxGridSizer.

In the following example we use two nested sizers, the main one with vertical layout and the embedded one with horizontal layout:

The sizer.Add method has three arguments. The first one specifies the control to include in the sizer. The second one is a weight factor which means that this control will be sized in proportion to other ones. For example, if you had three edit controls and you wanted them to have the proportions 3:2:1 then you would specify these factors as arguments when adding the controls. 0 means that this control or sizer will not grow. The third argument is normally wx.GROW (same as wx.EXPAND) which means the control will be resized when necessary. If you use wx.SHAPED instead, the controls aspect ratio will remain the same.

If the second parameter is 0, i.e. the control will not be resized, the third parameter may indicate if the control should be centered horizontally and/or vertically by using wx.ALIGN_CENTER_HORIZONTAL, wx.ALIGN_CENTER_VERTICAL, or wx.ALIGN_CENTER (for both) instead of wx.GROW or wx.SHAPED as that third parameter.

You can alternatively specify combinations of wx.ALIGN_LEFT, wx.ALIGN_TOP, wx.ALIGN_RIGHT, and wx.ALIGN_BOTTOM. The default behavior is equivalent to wx.ALIGN_LEFT | wx.ALIGN_TOP.

One potentially confusing aspect of the wx.Sizer and its sub-classes is the distinction between a sizer and a parent window. When you create objects to go inside a sizer, you do not make the sizer the object's parent window. A sizer is a way of laying out windows, it is not a window in itself. In the above example, all six buttons would be created with the parent window being the frame or window which encloses the buttons -- not the sizer. If you try to create a visual element and pass the sizer as the parent window, your program will crash.

Once you have set up your visual elements and added them to a sizer (or to a nested set of sizers), the next step is to tell your frame or window to use the sizer. You do this in three steps:

The SetSizer() call tells your window (or frame) which sizer to use. The call to SetAutoLayout() tells your window to use the sizer to position and size your components. And finally, the call to sizer.Fit() tells the sizer to calculate the initial size and position for all its elements. If you are using sizers, this is the normal process you would go through to set up your window or frame's contents before it is displayed for the first time.

Menus

TODO:

Validators

When you create a dialog box or other input form, you can use a wx.Validator to simplify the process of loading data into your form, validating the entered data, and extracting the data out of the form again. wx.Validator can also be used to intercept keystrokes and other events within an input field. To use a validator, you have to create your own sub-class of wx.Validator (neither wx.TextValidator nor wx.GenericValidator are implemented in wxPython). This sub-class is then associated with your input field by calling myInputField.SetValidator(myValidator).

This design should be clear and you should not have any problem with it if you read the Small Editor section of this howto. Note: a sizer should be used here instead of specifying the position of each widget. Notice in the line:

the use of panel as parent parameter of our wxStaticText. Our Static text is going to be on the panel we have created just before. The wxPoint is used as positioning parameter. There is also an optional wxSize parameter but its use here is not justified.

[7] According to wxPython documentation:

"A panel is a window on which controls are placed. It is usually placed within a frame. It contains minimal extra functionality over and above its parent class wxWindow; its main purpose is to be similar in appearance and functionality to a dialog, but with the flexibility of having any window as a parent.", in fact, it is a simple window used as a (grayed) background for other objects which are meant to deal with data entry. These are generally known as Controls or Widgets.

[8] A label is used to display text that is not supposed to interact with the user.

Adding a few more controls

You will find a complete list of the numerous Controls that exist in wxPython in the demo and help, but here we are going to present those most frequently used:

wxButton The most basic Control: A button showing a text that you can click. For example, here is a "Clear" button (e.g. to clear a text):

those controls react. We have added a special wxTextCtrl control to show the various events that are sent by the controls.

The notebook

Sometimes, a form grows too big to fit on a single page. The

wxNoteBook is used in that kind of case : It allows the user to navigate quickly between a small amount of pages by clicking on associated tabs. We implement this by putting the wxNotebook instead of our form into the main Frame and then add our Form1 into the notebook by using method AddPage.

Improving the layout - Using Sizers

Using absolute positioning is often not very satisfying: The result is ugly if the windows are not (for one reason or another) the

right size. WxPython has very rich vocabulary of objects to lay out controls.

wx.BoxSizer is the most common and simple layout object but it permits a vast range of possibilities. Its role is roughly to arrange a set of controls in a line or in a row and rearrange them when needed (i.e. when the global size is changed).

wx.GridSizer and wx.FlexGridSizer are two very important layout tools. They arrange the controls in a tabular layout.

This example uses a GridBagSizer to place its items. The "pos" argument controls where in the grid the widget is placed, in (x, y) positions. For instance, (0, 0) is the top-left position, whereas (3, 5) would be the third row down, and the fifth column across. The span argument allows a widget to span over multiple rows or columns.

Responding to User Actions

Topics:

Events

Pop-up Menus

Overview

Concepts to go here.

A Working Example

TODO: Example to go here.

Drawing

Topics:

Device Contexts

Fonts

Colours

onPaint() methods

Overview

In this section, we shall try to introduce the way to draw inside a window. We'll also show how to create a menu that pops up when there is a right-click inside the main window.

A Working Example

Using wxPython

Debugging Techniques

When a python program hits an unhandled exception (bug!) in your program, it aborts with a traceback that is useful in locating the source of the problem. wxPython programs do the same, but with a twist. The traceback is routed to stdio, which is captured in a nice GUI frame independent of your program. If an exception shows up in an event handler, the traceback is displayed, and your program continues on as best it can. BUT, if the exception occurs while initializing your program, the traceback will show up, and then your program will abort, taking the stdio window (and your traceback) with it before even the fastest reader can make sense of it. You can keep stdio from being hijacked by wxPython by providing a couple of optional parameters when you instantiate your wxApp. An example says it best:

1classMyApp (wx.App): 2#... 3#... 4#... 5myapp = MyApp() # functions normally. Stdio is redirected to its own window 6myapp = MyApp(0) #does not redirect stdout. Tracebacks will show up at the console. 7myapp = MyApp(1, 'filespec') #redirects stdout to the file 'filespec' 8# NOTE: These are named parameters, so you can do this for improved readability: 9myapp = MyApp(redirect = 1, filename = 'filespec') # will redirect stdout to 'filespec' 10myapp = MyApp(redirect = 0) #stdio will stay at the console...

PyCrust interactive shell

wxPython distribution comes with the nice PyCrust shell. With it you can interactvely test your layout. Here is a with a sample code.

Deploying your wxPython Application

Next Steps

Events

Event handling is one of the key feature of wxPython. All GUI systems known to us rely on events to distribute information between various applications. Deciding what to do when a particular event is received is every GUI-application's job and is called Event Handling. Back in the old days before object programming, dealing with events meant you would have a "switch" operation that decided what to do with a particular type of event. With the arrival of Object Oriented Programming things are not that simple any more : There are now two ways of handling events:

One method (e.g. Java one) relies on what are called event handlers. Event handlers are attached to a particular object and bound to a callback function/method. When the object receives a particular type of event, the event handler triggers the callback function.

The other approach is to give predetermined names to methods that are supposed to handle a particular event. This way, if you want to modify the response of a particular class to a particular event, you have to derive your class and overload the right method.

wxPython combines these two approaches. You can define event handlers along with deriving classes to implement new behaviours.

So then "self.Bind(wx.EVT_SOMETHING, ACallable)" would mean:

When a SOMETHING event is delivered to this Window (self), and it comes from any child window or itself, then call ACallable, and self must be a class derived from a wxPython window (e.g. a Button, a Dialog, a Frame), and "ACallable" can be any function, though the usual choice by the programmer is to make it a function within the above-mentioned class.

The second version "self.Bind(wx.EVT_SOMETHING, ACallable, srcWin)" means:

When a SOMETHING event is generated by "srcWin", and it comes up through the window hierarchy to this Window (self), then call ACallable.

But some events can only be caught in the Window in which they are generated (which means the second form then won't do anything), so it is best to use the first form whenever possible, which would be basically everywhere except for menu items, which don't have a Bind() method.

Boa-constructor

multi threading

Managed/ Non Managed windows

Useful resources

To start with, a very obvious website but you can also have a look in the demo shipped in with the wxPython package. It's full of very useful examples approaching nearly all the subjects you can think of. How to run the demo:

under windows Simply select the program Run The Demo in the submenu wxPython of the start menu.

under Linux find the demo directory in the source distribution and run "python demo.py"

You can also try to find information on the wxWidgets website. wxPython's documentation contains all wxWidgets', so it's a bit pointless going there if you've already had a look at wxPython's documentation.

With this tool, you can convert Python (and also wxPython scripts...) scripts into standalone windows programs. This makes it it easy to distribute your work.

As a conclusion- slithering our way to the future of GUI-apps

You have now covered the main aspects of wxPython programming and should be able to start writing wxPython applications. Do not hesitate to take part in the wxPython community by subscribing to the mailing lists and by posting questions or answers on those lists.

OS independent path concatenation

...can still cause problems on Windows in cases where you've used the common dialog to navigate to the root dir of the drive. In that case, the common dialog function will return self.dirname='c:' (you'd expect 'c:\' unless you've dealt with MS for many years). Unfortunately, os.path.join won't join as expected when the string contains a ':', and so an error occurs when opening 'c:file.py', since this is dependent on the cwd setting (assuming 'file.py' exists in 'c:\', but not in your cwd).

without any problems. I presume that lower level functions like "open" probably call os.path.normpath() which fixes it on Windows. The advantage to this is that I can use the same method ('/') for directories & URL's, and the code runs cross-platform Win/Linux. I'm sure it will get me someday, though. A better option would probably be:

I think this works for all cases except where self.dirname is 'c:\' before you start (normpath won't strip extra separators on the 1st join arg). Or perhaps an elegant solution using os.path.isabs() would be better.

Kevin Vap

Use the sizer in one step

I always thought setting sizer must be shorter than three lines an indeed it is (at least for wxWidgets/wxPython 2.4), the used above

How to get tabs to work

It's beeen really hard to me getting tabs to work in non-dialog windows: the only hint in the whole documentation is in wxWindow style wxTAB_TRAVERSAL description, but it's not so clear. What I finally got was:

1)For the tabbing to work at all, the window or individual panel you plonk controls/wigits on has to have as part of its style flag the following: wxTAB_TRAVERSAL ie;

2) The tab order is set by the order you add controls to the panel or frame.

(information comes from)

Massimiliano Sartor

3) Tabbing order also seems to be dependent in the order widgets are created. I assume this is due to widget ID numbers. Order of addition to sizers/panels did not seem to help me with #2. -- Keith Veleba

4) Here's a little idiom for setting tab order once you have the controls set up: