-Introduction
-------------
-The code in this subtree is a Python Extension Module that enables the
-use of wxWindows from the Python language. So what is Python? Go to
-http://www.python.org to learn more but in a nutshell, it's an
-extremly cool object oriented language. It's easier than Perl and
-nearly as powerful. It runs on more platforms than Java, and by some
-reports, is even faster than Java with a JIT compiler!
-
-So why would you want to use wxPython over just C++ and wxWindows?
-Personally I prefer using Python for everything. I only use C++ when
-I absolutly have to eek more performance out of an algorithm, and even
-then I ususally code it as an extension module and leave the majority
-of the program in Python. Another good thing to use wxPython for is
-quick prototyping of your wxWindows apps. With C++ you have to
-continuously go though the edit-compile-link-run cycle, which can be
-quite time comsuming. With Python it is only an edit-run cycle. You
-can easily build an application in a few hours with Python that would
-normally take a few days with C++. Converting a wxPython app to a
-C++/wxWindows app should be a straight forward task.
-
-This extension module attempts to mirror the class heiarchy of
-wxWindows as closely as possble. This means that there is a wxFrame
-class in wxPython that looks, smells, tastes and acts almost the same
-as the wxFrame class in the C++ version. Unfortunatly, I wasn't able
-to match things exactly because of differences in the languages, but
-the differences should be easy to absorb because they are natural to
-Python. For example, some methods that return mutliple values via
-argument pointers in C++ will return a tuple of values in Python.
-These differences have not been documented yet so if something isn't
-working the same as described in the wxWindows documents the best
-thing to do is to scan through the wxPython sources, especially the .i
-files, as that is where the interfaces for wxPython are defined.
-
-Currently this extension module is designed such that the entire
-application will be written in Python. I havn't tried it yet, but I
-am sure that attempting to embed wxPython in a C++ wxWindows
-application will cause problems. However there is a plan to support
-this in the future.
-
-
-
-What's new in 0.4.2
--------------------
-
-wxPython on wxGTK works!!! Both dynamic and static on Linux and
-static on Solaris have been tested. Many thanks go to Harm
-<H.v.d.Heijden@phys.tue.nl> for his astute detective work on tracking
-down a nasty DECREF bug. Okay so I have to confess that it was just a
-DSM (Dumb Stupid Mistake) on my part but it was nasty none the less
-because the behavior was so different on different platforms.
-
-
-The dynamicly loaded module on Solaris is still segfaulting, so it
-must have been a different issue all along...
-
-
-
-What's New in 0.4
------------------
-
-1. Worked on wxGTK compatibility. It is partially working. On a
-Solaris/Sparc box wxPython is working but only when it is statically
-linked with the Python interpreter. When built as a dyamically loaded
-extension module, things start acting weirdly and it soon seg-faults.
-And on Linux both the statically linked and the dynamically linked
-version segfault shortly after starting up.
-
-2. Added Toolbar, StatusBar and SplitterWindow classes.
-
-3. Varioius bug fixes, enhancements, etc.
projects / wxWidgets.git / blobdiff