Update of /cvsroot/pycrust/wx/examples
In directory sc8-pr-cvs1:/tmp/cvs-serv14471
Added Files:
examples.txt
Log Message:
Examples doc.
--- NEW FILE: examples.txt ---
=================================
Example Programs Using wxPython
=================================
--------------------------------------------------
A survival guide for the post-wx-prefixed world.
--------------------------------------------------
:Author: Patrick K. O'Brien
:Contact: po...@or...
:Date: $Date: 2003/03/21 20:37:04 $
:Revision: $Revision: 1.1 $
.. contents::
Introduction
============
If something hits you on the head, don't run around screaming that the
sky is falling. Instead, take a close look and see if it wasn't a
"wx" prefix that hit you. Apparently, they're dropping off wxPython
class names like flies dropping dead in the scorching heat of a
summer's day.
Yes, the world is changing, and even our little wxPython world must
change with it. Then again, I'm not fond of pesky summertime flies,
and I'm not too upset that the "wx" prefixes are going to bite the
dust. I think it's for the best. But, being the kind, considerate
person that I am, I decided to write this guide to make the wx
namespace transition easier for everyone, even Chicken Little.
.. sidebar:: Say what?
If you have no idea what I mean by the "wx namespace transition,"
consider yourself lucky. You can simply use these examples to
learn wxPython in its current state. All you need to know is that
previous wxPython code used a slightly different syntax that some
folks (including me) considered ugly. So we changed it. And
that's when the sky starting falling...
Rather than simply **tell** you that everything will be okay, I
decided to **show** you that everything will be okay. To do that,
I've created a bunch of example programs using the new wx package. I
hope you like them.
Basic
=====
It doesn't get much simpler than this. Every wxPython program needs
an application and a frame. To encourage good coding habits, I've
split them into separate modules. They don't do much, but they're a
good starting point.
I include a simple App class in the frame module because the PyCrust
"wrapper" utility (``wrap.py``) only works with modules that contain
an application class. So including a simple one in each of your frame
modules allows you to use the PyCrust runtime wrapper and debug your
frames independent of your full application.
Here is the module (``frame.py``) that defines the frame class:
.. include:: basic/frame.py
:literal:
And here is the module (``app.py``) that defines the application class
and imports the frame from ``frame.py``:
.. include:: basic/app.py
:literal:
Hello
=====
This program displays an image file (``wxPython.jpg``) inside a frame
sized to match the graphic.
.. figure:: screenshots/hello-win98.png
:scale: 100
Running ``hello.py`` on Windows.
.. figure:: screenshots/hello-linux.png
:scale: 100
Running ``hello.py`` on Linux.
.. figure:: screenshots/hello-mac.png
:scale: 100
Running ``hello.py`` on Mac OS X.
Here is the source code for ``hello.py``:
.. include:: hello/hello.py
:literal:
|
