Other doc updates
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@26380 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
parent
5444f3a944
commit
90805926b7
@ -244,8 +244,9 @@ wxUSE_AFM_FOR_POSTSCRIPT 0
|
||||
wxUSE_DISPLAY 1
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">Make a %WXWIN%BIN directory and add it to the PATH. My build
|
||||
scripts will copy the wxWidgets DLLs there.</p>
|
||||
<li><p class="first">Make sure that %WXWIN%libvc_dll directory is on the PATH. The
|
||||
wxWidgets DLLs will end up there as part of the build and so you'll
|
||||
need it on the PATH for them to be found at runtime.</p>
|
||||
</li>
|
||||
<li><p class="first">Change to the %WXWIN%buildmsw directory and copy my build scripts
|
||||
there.</p>
|
||||
@ -325,7 +326,7 @@ python demo.py
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -11,7 +11,7 @@
|
||||
<div class="document" id="changes-txt-for-wxpython">
|
||||
<h1 class="title">CHANGES.txt for wxPython</h1>
|
||||
<div class="section" id="id1">
|
||||
<h1><a name="id1">2.5.1.1</a></h1>
|
||||
<h1><a name="id1">2.5.1.2</a></h1>
|
||||
<p>(See also the MigrationGuide.txt file for details about some of the
|
||||
big changes that have happened in this release and how you should
|
||||
adapt your code.)</p>
|
||||
@ -73,6 +73,23 @@ MacPrintFile, MacNewFile, and MacReopenApp.</p>
|
||||
<p>Added wx.PlatformInfo which is a tuple containing strings that
|
||||
describe the platform and build options of wxPython. See the
|
||||
MigrationGuide for more details.</p>
|
||||
<p>Created a new extension module "activex" from Lindsay Mathieson's
|
||||
newest <a class="reference" href="http://members.optusnet.com.au/~blackpaw1/wxactivex.html">wxActiveX</a> class. (The existing iewin module used an older
|
||||
version of this code, but only exposed the wxIEHtmlWin class.) This
|
||||
new module will (in theory ;-) ) allow you to host arbitrary ActiveX
|
||||
controls in a wx.Window, <strong>without</strong> requiring the use of the win32com
|
||||
and other PyWin32 modules! This should eliminate the cronic problems
|
||||
that have resulted from minor mismatches in how PyWin32 handles the
|
||||
GIL and tstate when making callbacks, etc. The older iewin module
|
||||
will be left in this release as the new stuff is not fully backwards
|
||||
compatible, but you should migrate your code to the new IEHtmlWindow
|
||||
in wx.lib.iewin, so the old one can be eventually removed.
|
||||
Additionally, I've always considered that the wx.lib.activexwrapper
|
||||
module is an ugly hack that I only included in the lib because I
|
||||
couldn't figure out anything better. Well now we have something that,
|
||||
if it isn't already, has the potential to be better. So consider
|
||||
migrating away from using activexwrapper as well. Please see the
|
||||
MigrationGuide for more details on using the new module.</p>
|
||||
</div>
|
||||
<div class="section" id="id2">
|
||||
<h1><a name="id2">2.4.2.4</a></h1>
|
||||
@ -1227,7 +1244,7 @@ version segfault shortly after starting up.</p>
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -1,7 +1,7 @@
|
||||
CHANGES.txt for wxPython
|
||||
=====================================================================
|
||||
|
||||
2.5.1.1
|
||||
2.5.1.2
|
||||
-------
|
||||
|
||||
(See also the MigrationGuide.txt file for details about some of the
|
||||
@ -96,15 +96,14 @@ and other PyWin32 modules! This should eliminate the cronic problems
|
||||
that have resulted from minor mismatches in how PyWin32 handles the
|
||||
GIL and tstate when making callbacks, etc. The older iewin module
|
||||
will be left in this release as the new stuff is not fully backwards
|
||||
compatible, but you should migrate your code to the wx.activex version
|
||||
of IEHtmlWindow, or the implementation in wx.lib.iewin, so the old one
|
||||
can be eventually removed. Additionally, I've always considered that
|
||||
the wx.lib.activexwrapper module is an ugly hack that I only included
|
||||
in the lib because I couldn't figure out anything better. Well now we
|
||||
have something that, if it isn't already, has the potential to be
|
||||
better. So consider migrating away from using activexwrapper as well.
|
||||
Please see the MigrationGuide for more details on using the new
|
||||
module.
|
||||
compatible, but you should migrate your code to the new IEHtmlWindow
|
||||
in wx.lib.iewin, so the old one can be eventually removed.
|
||||
Additionally, I've always considered that the wx.lib.activexwrapper
|
||||
module is an ugly hack that I only included in the lib because I
|
||||
couldn't figure out anything better. Well now we have something that,
|
||||
if it isn't already, has the potential to be better. So consider
|
||||
migrating away from using activexwrapper as well. Please see the
|
||||
MigrationGuide for more details on using the new module.
|
||||
|
||||
.. _wxActiveX: http://members.optusnet.com.au/~blackpaw1/wxactivex.html
|
||||
|
||||
|
@ -128,7 +128,7 @@ python setup.py install
|
||||
found at runtime by the extension modules without requiring that
|
||||
they be installed on the PATH:</p>
|
||||
<pre class="literal-block">
|
||||
copy %WXWIN%\BIN\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx
|
||||
copy %WXWIN%\lib\vc_dll\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx
|
||||
</pre>
|
||||
</li>
|
||||
</ol>
|
||||
@ -136,7 +136,7 @@ copy %WXWIN%\BIN\wx*h_*.dll c:\Python23\Lib\site-pacakges\wx
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -393,6 +393,107 @@ way. If there are any other platform/toolkit/build flags that make
|
||||
sense to add to this tuple please let me know.</p>
|
||||
<p>BTW, wx.Platform will probably be deprecated in the future.</p>
|
||||
</div>
|
||||
<div class="section" id="activex">
|
||||
<h1><a name="activex">ActiveX</a></h1>
|
||||
<p>Lindsay Mathieson's newest <a class="reference" href="http://members.optusnet.com.au/~blackpaw1/wxactivex.html">wxActiveX</a> class has been wrapped into a new
|
||||
extension module called wx.activex. It is very generic and dynamic
|
||||
and should allow hosting of arbitray ActiveX controls within your
|
||||
wxPython apps. So far I've tested it with IE, PDF, and Flash
|
||||
controls, (and there are new samples in the demo and also library
|
||||
modules supporting these.)</p>
|
||||
<p>The new wx.activex module contains a bunch of code, but the most
|
||||
important things to look at are ActiveXWindow and ActiveXEvent.
|
||||
ActiveXWindow derives from wxWindow and the constructor accepts a
|
||||
CLSID for the ActiveX Control that should be created. (There is also
|
||||
a CLSID class that can convert from a progID or a CLSID String.) The
|
||||
ActiveXWindow class simply adds methods that allow you to query some
|
||||
of the TypeInfo exposed by the ActiveX object, and also to get/set
|
||||
properties or call methods by name. The Python implementation
|
||||
automatically handles converting parameters and return values to/from
|
||||
the types expected by the ActiveX code as specified by the TypeInfo,
|
||||
(just bool, integers, floating point, strings and None/Empty so far,
|
||||
but more can be handled later.)</p>
|
||||
<p>That's pretty much all there is to the class, as I mentioned before it
|
||||
is very generic and dynamic. Very little is hard-coded and everything
|
||||
that is done with the actual ActiveX control is done at runtime and
|
||||
referenced by property or method name. Since Python is such a dynamic
|
||||
language this is a very good match. I thought for a while about doing
|
||||
some Python black-magic and making the specific methods/properties of
|
||||
the actual ActiveX control "appear" at runtime, but then decided that
|
||||
it would be better and more understandable to do it via subclassing.
|
||||
So there is a utility class in wx.activex that given an existing
|
||||
ActiveXWindow instance can generate a .py module containing a derived
|
||||
class with real methods and properties that do the Right Thing to
|
||||
reflect those calls to the real ActiveX control. There is also a
|
||||
script/tool module named genaxmodule that given a CLSID or progID and
|
||||
a class name, will generate the module for you. There are a few
|
||||
examples of the output of this tool in the wx.lib package, see
|
||||
iewin.py, pdfwin.py and flashwin.py.</p>
|
||||
<p>Currently the genaxmodule tool will tweak some of the names it
|
||||
generates, but this can be controled if you would like to do it
|
||||
differently by deriving your own class from GernerateAXModule,
|
||||
overriding some methods and then using this class from a tool like
|
||||
genaxmodule. [TODO: make specifying a new class on genaxmodule's
|
||||
command-line possible.] The current default behavior is that any
|
||||
event names that start with "On" will have the "On" dropped, property
|
||||
names are converted to all lower case, and if any name is a Python
|
||||
keyword it will have an underscore appended to it. GernerateAXModule
|
||||
does it's best when generating the code in the new module, but it can
|
||||
only be as good as the TypeInfo data available from the ActiveX
|
||||
control so sometimes some tweaking will be needed. For example, the
|
||||
IE web browser control defines the Flags parameter of the Navigate2
|
||||
method as required, but MSDN says it is optional.</p>
|
||||
<p>It is intended that this new wx.activex module will replace both the
|
||||
older version of Lindsay's code available in iewin.IEHtmlWindow, and
|
||||
also the wx.lib.activexwraper module. Probably the biggest
|
||||
differences you'll ecounter in migrating activexwrapper-based code
|
||||
(besides events working better without causing deadlocks) is that
|
||||
events are no longer caught by overriding methods in your derived
|
||||
class. Instead ActiveXWindow uses the wx event system and you bind
|
||||
handlers for the ActiveX events exactly the same way you do for any wx
|
||||
event. There is just one extra step needed and that is creating an
|
||||
event ID from the ActiveX event name, and if you use the genaxmodule
|
||||
tool then this extra step will be handled for you there. For example,
|
||||
for the StatusTextChange event in the IE web browser control, this
|
||||
code is generated for you:</p>
|
||||
<pre class="literal-block">
|
||||
wxEVT_StatusTextChange = wx.activex.RegisterActiveXEvent('StatusTextChange')
|
||||
EVT_StatusTextChange = wx.PyEventBinder(wxEVT_StatusTextChange, 1)
|
||||
</pre>
|
||||
<p>and you would use it in your code like this:</p>
|
||||
<pre class="literal-block">
|
||||
self.Bind(iewin.EVT_StatusTextChange, self.UpdateStatusText, self.ie)
|
||||
</pre>
|
||||
<p>When the event happens and your event handler function is called the
|
||||
event properties from the ActiveX control (if any) are converted to
|
||||
attributes of the event object passed to the handler. (Can you say
|
||||
'event' any more times in a single sentence? ;-) ) For example the
|
||||
StatusTextChange event will also send the text that should be put into
|
||||
the status line as an event parameter named "Text" and you can access
|
||||
it your handlers as an attribute of the event object like this:</p>
|
||||
<pre class="literal-block">
|
||||
def UpdateStatusText(self, evt):
|
||||
self.SetStatusText(evt.Text)
|
||||
</pre>
|
||||
<p>Usually these event object attributes should be considered read-only,
|
||||
but some will be defined by the TypeInfo as output parameters. In
|
||||
those cases if you modify the event object's attribute then that value
|
||||
will be returned to the ActiveX control. For example, to prevent a
|
||||
new window from being opened by the IE web browser control you can do
|
||||
this in the handler for the iewin.EVT_NewWindow2 event:</p>
|
||||
<pre class="literal-block">
|
||||
def OnNewWindow2(self, evt):
|
||||
evt.Cancel = True
|
||||
</pre>
|
||||
<p>So how do you know what methods, events and properties that am ActiveX
|
||||
control supports? There is a funciton in wx.activex named GetAXInfo
|
||||
that returns a printable summary of the TypeInfo from the ActiveX
|
||||
instance passed in. You can use this as an example of how to browse
|
||||
the TypeInfo provided, and there is also a copy of this function's
|
||||
output appended as a comment to the modules produced by the
|
||||
genaxmodule tool. Beyond that you'll need to consult the docs
|
||||
provided by the makers of the ActiveX control that you are using.</p>
|
||||
</div>
|
||||
<div class="section" id="other-stuff">
|
||||
<h1><a name="other-stuff">Other Stuff</a></h1>
|
||||
<p>Instead of over a dozen separate extension modules linked together
|
||||
@ -422,18 +523,34 @@ wxPyTypeCast at all.</p>
|
||||
there are compatibility aliases for much of the above items.</p>
|
||||
<p>The wxWave class has been renamed to wxSound, and now has a slightly
|
||||
different API.</p>
|
||||
<p>Instead of a very small 20x20 the default window size is now a more
|
||||
reasonable size, (currently 400x250 but that may change...) If you
|
||||
don't specify a size, and the window/control class does not have any
|
||||
definition of it's own "best size" (most controls do) then the new
|
||||
default will be used. If you have code that accidentally depends on
|
||||
the smaller size then things will look a bit odd. To work around this
|
||||
just give those windows an explicit size when created.</p>
|
||||
<p>wx.TaskbarIcon works on wxGTK-based platforms now, however you have to
|
||||
manage it a little bit more than you did before. Basically, the app
|
||||
will treat it like a top-level frame in that if the wx.TaskBarIcon
|
||||
still exists when all the frames are closed then the app will still
|
||||
not exit. You need to ensure that the wx.TaskBarIcon is destroyed
|
||||
when your last Frame is closed. For wxPython apps it is usually
|
||||
enough if your main frame object holds the only reference to the
|
||||
wx.TaskBarIcon, then when the frame is closed Python reference
|
||||
counting takes care of the rest.</p>
|
||||
<p>If you are embedding wxPython in a C++ app, or are writing wxPython
|
||||
compatible extensions modules, then the usage of wxPyBeginAllowThreads
|
||||
and wxPyEndAllowThreads has changed slightly. wxPyBeginAllowThreads
|
||||
now returns a boolean value that must be passed to the coresponding
|
||||
wxPyEndAllowThreads function call. This is to help do the RightThing
|
||||
when calls to these two functions are nested, or if calls to external
|
||||
code in other extension modules that are wrapped in the standard
|
||||
Py_(BEGIN|END)_ALLOW_THERADS may result in wx event handlers being
|
||||
called (such as during the call to os.startfile.)</p>
|
||||
<p>The bulk of wxPython's setup.py has been moved to another module,
|
||||
wx/build/config.py. This module will be installed as part of wxPython
|
||||
so 3rd party modules that wish to use the same setup/configuration
|
||||
code can do so simply by importing this module from their own setup.py
|
||||
scripts.</p>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -111,8 +111,8 @@ point where I thought the original PyCrust name was too confining. I
|
||||
was using the PyCrust code base to develop programs that weren't just
|
||||
Python shells any more.</p>
|
||||
<p>Around that same time, the wxPython folks asked me if I'd be willing
|
||||
to move all my wxPython-related projects into the <a class="reference" href="http://cvs.wxwindows.org">wxPython CVS
|
||||
repository</a>, and become part of the <a class="reference" href="http://www.wxpython.org/">wxPython</a>/<a class="reference" href="http://www.wxwindows.org/">wxWindows</a> developer team.
|
||||
to move all my wxPython-related projects into the <a class="reference" href="http://cvs.wxWidgets.org">wxPython CVS
|
||||
repository</a>, and become part of the <a class="reference" href="http://www.wxpython.org/">wxPython</a>/<a class="reference" href="http://www.wxWidgets.org/">wxWidgets</a> developer team.
|
||||
I decided the time was right to restructure the PyCrust project.
|
||||
During the move, the PyCrust package was renamed to "py" (lowercase
|
||||
"p") and the collection of programs and modules as a whole became
|
||||
@ -182,8 +182,8 @@ underlying <tt class="literal"><span class="pre">filling</span></tt> module.</p>
|
||||
as PyCrust, but doesn't have any of the extra features that appear in
|
||||
the PyCrust notebook interface.</p>
|
||||
<div class="figure">
|
||||
<p><img alt="/screenshots/PyShell.png" src="/screenshots/PyShell.png" /></p>
|
||||
<p class="caption">PyShell running on Mandrake Linux 9.1.</p>
|
||||
<p><img alt="screenshots/PyShell.png" src="screenshots/PyShell.png" /></p>
|
||||
<p class="caption">PyShell running on Mandrake Linux.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="pywrap">
|
||||
@ -238,7 +238,7 @@ programs and modules, since the beginning.</p>
|
||||
* wxPython Docs
|
||||
* wxSTC Docs</p>
|
||||
<p>Fixed Calltip tab refresh problem on Windows.</p>
|
||||
<p>shell.autoCompleteAutoHide added with default of True.</p>
|
||||
<p>shell.autoCompleteAutoHide added with default of False.</p>
|
||||
<p>Changed default namespace of Shell to __main__.__dict__, instead of an
|
||||
empty dictionary.</p>
|
||||
</div>
|
||||
@ -700,7 +700,7 @@ needed. PyCrust had to happen...</p>
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -67,15 +67,15 @@ Python shells any more.
|
||||
|
||||
Around that same time, the wxPython folks asked me if I'd be willing
|
||||
to move all my wxPython-related projects into the `wxPython CVS
|
||||
repository`_, and become part of the wxPython_/wxWindows_ developer team.
|
||||
repository`_, and become part of the wxPython_/wxWidgets_ developer team.
|
||||
I decided the time was right to restructure the PyCrust project.
|
||||
During the move, the PyCrust package was renamed to "py" (lowercase
|
||||
"p") and the collection of programs and modules as a whole became
|
||||
known as "Py" (with a capital "P").
|
||||
|
||||
.. _wxPython CVS repository: http://cvs.wxwindows.org
|
||||
.. _wxPython CVS repository: http://cvs.wxWidgets.org
|
||||
.. _SourceForge: http://www.sf.net/projects/pycrust/
|
||||
.. _wxWindows: http://www.wxwindows.org/
|
||||
.. _wxWidgets: http://www.wxWidgets.org/
|
||||
|
||||
The original goal of PyCrust was to be the best interactive, graphical
|
||||
Python shell (of course, I claimed it was the "flakiest" Python
|
||||
@ -155,9 +155,9 @@ PyShell is an interactive, Python shell. It shares the same base code
|
||||
as PyCrust, but doesn't have any of the extra features that appear in
|
||||
the PyCrust notebook interface.
|
||||
|
||||
.. figure:: /screenshots/PyShell.png
|
||||
.. figure:: screenshots/PyShell.png
|
||||
|
||||
PyShell running on Mandrake Linux 9.1.
|
||||
PyShell running on Mandrake Linux.
|
||||
|
||||
|
||||
PyWrap
|
||||
|
@ -60,7 +60,7 @@ Robin Dunn
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
BIN
wxPython/docs/screenshots/PyShell.png
Normal file
BIN
wxPython/docs/screenshots/PyShell.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 35 KiB |
@ -163,15 +163,101 @@ replace.</p>
|
||||
</div>
|
||||
<div class="section" id="where-can-i-find-example-programs-using-the-new-wx-syntax">
|
||||
<h1><a class="toc-backref" href="#id9" name="where-can-i-find-example-programs-using-the-new-wx-syntax">Where can I find example programs using the new wx syntax?</a></h1>
|
||||
<p>Example programs are included in the wxPython/samples/wx_examples
|
||||
directory, and are documented in the <a class="reference" href="wxPythonExamples.html">wxPythonExamples</a> documentation
|
||||
file. Also, all the code in the py package uses the new wx syntax.
|
||||
You can learn more about these in the <a class="reference" href="PyManual.html">PyManual</a>.</p>
|
||||
<p>The wxPython demo application and most of the sample apps have been
|
||||
converted to use the new <tt class="literal"><span class="pre">import</span> <span class="pre">wx</span></tt> style of programming with
|
||||
wxPython, so there are lots of examples to look at and to play with.
|
||||
Here is one of them, it is the <tt class="literal"><span class="pre">simple</span></tt> sample.</p>
|
||||
<pre class="literal-block">
|
||||
#----------------------------------------------------------------------
|
||||
# A very simple wxPython example. Just a wxFrame, wxPanel,
|
||||
# wxStaticText, wxButton, and a wxBoxSizer, but it shows the basic
|
||||
# structure of any wxPython application.
|
||||
#----------------------------------------------------------------------
|
||||
|
||||
import wx
|
||||
|
||||
|
||||
class MyFrame(wx.Frame):
|
||||
"""
|
||||
This is MyFrame. It just shows a few controls on a wxPanel,
|
||||
and has a simple menu.
|
||||
"""
|
||||
def __init__(self, parent, title):
|
||||
wx.Frame.__init__(self, parent, -1, title,
|
||||
pos=(150, 150), size=(350, 200))
|
||||
|
||||
# Create the menubar
|
||||
menuBar = wx.MenuBar()
|
||||
|
||||
# and a menu
|
||||
menu = wx.Menu()
|
||||
|
||||
# add an item to the menu, using \tKeyName automatically
|
||||
# creates an accelerator, the third param is some help text
|
||||
# that will show up in the statusbar
|
||||
menu.Append(wx.ID_EXIT, "E&xit\tAlt-X", "Exit this simple sample")
|
||||
|
||||
# bind the menu event to an event handler
|
||||
self.Bind(wx.EVT_MENU, self.OnTimeToClose, id=wx.ID_EXIT)
|
||||
|
||||
# and put the menu on the menubar
|
||||
menuBar.Append(menu, "&File")
|
||||
self.SetMenuBar(menuBar)
|
||||
|
||||
self.CreateStatusBar()
|
||||
|
||||
|
||||
# Now create the Panel to put the other controls on.
|
||||
panel = wx.Panel(self)
|
||||
|
||||
# and a few controls
|
||||
text = wx.StaticText(panel, -1, "Hello World!")
|
||||
text.SetFont(wx.Font(14, wx.SWISS, wx.NORMAL, wx.BOLD))
|
||||
text.SetSize(text.GetBestSize())
|
||||
btn = wx.Button(panel, -1, "Close")
|
||||
funbtn = wx.Button(panel, -1, "Just for fun...")
|
||||
|
||||
# bind the button events to handlers
|
||||
self.Bind(wx.EVT_BUTTON, self.OnTimeToClose, btn)
|
||||
self.Bind(wx.EVT_BUTTON, self.OnFunButton, funbtn)
|
||||
|
||||
# Use a sizer to layout the controls, stacked vertically and with
|
||||
# a 10 pixel border around each
|
||||
sizer = wx.BoxSizer(wx.VERTICAL)
|
||||
sizer.Add(text, 0, wx.ALL, 10)
|
||||
sizer.Add(btn, 0, wx.ALL, 10)
|
||||
sizer.Add(funbtn, 0, wx.ALL, 10)
|
||||
panel.SetSizer(sizer)
|
||||
panel.Layout()
|
||||
|
||||
|
||||
def OnTimeToClose(self, evt):
|
||||
"""Event handler for the button click."""
|
||||
print "See ya later!"
|
||||
self.Close()
|
||||
|
||||
def OnFunButton(self, evt):
|
||||
"""Event handler for the button click."""
|
||||
print "Having fun yet?"
|
||||
|
||||
|
||||
class MyApp(wx.App):
|
||||
def OnInit(self):
|
||||
frame = MyFrame(None, "Simple wxPython App")
|
||||
frame.Show(True)
|
||||
self.SetTopWindow(frame)
|
||||
return True
|
||||
|
||||
app = MyApp(True)
|
||||
app.MainLoop()
|
||||
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -157,10 +157,12 @@ replace.
|
||||
Where can I find example programs using the new wx syntax?
|
||||
==========================================================
|
||||
|
||||
Example programs are included in the wxPython/samples/wx_examples
|
||||
directory, and are documented in the wxPythonExamples_ documentation
|
||||
file. Also, all the code in the py package uses the new wx syntax.
|
||||
You can learn more about these in the PyManual_.
|
||||
The wxPython demo application and most of the sample apps have been
|
||||
converted to use the new ``import wx`` style of programming with
|
||||
wxPython, so there are lots of examples to look at and to play with.
|
||||
Here is one of them, it is the ``simple`` sample.
|
||||
|
||||
|
||||
.. include:: ../samples/simple/simple.py
|
||||
:literal:
|
||||
|
||||
.. _wxPythonExamples: wxPythonExamples.html
|
||||
.. _PyManual: PyManual.html
|
||||
|
@ -1074,7 +1074,7 @@ As such, it adheres to the same license, which is provided here:</p>
|
||||
</div>
|
||||
<hr class="footer" />
|
||||
<div class="footer">
|
||||
Generated on: 2004-03-12 19:55 UTC.
|
||||
Generated on: 2004-03-26 21:09 UTC.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -23,12 +23,12 @@ Introduction
|
||||
|
||||
This is a guide to the wxPython GUI toolkit, written **by** a Python
|
||||
programmer **for** his fellow Python programmers. It began as a
|
||||
simple translation of the wxWindows documentation (which is written
|
||||
simple translation of the wxWidgets documentation (which is written
|
||||
for C++ programmers), and evolved from there. And while there's
|
||||
nothing wrong with C++...
|
||||
|
||||
Okay, you got me there. I hate C++. That's why I use Python. If you
|
||||
like C++, go read the wxWindows documentation. If you'd rather read a
|
||||
like C++, go read the wxWidgets documentation. If you'd rather read a
|
||||
guide that's written with Python programmers in mind, keep reading
|
||||
this one. If you like it, feel free to send me freshly roasted coffee
|
||||
beans, dark chocolate, and large denomination currency. Better yet,
|
||||
@ -43,9 +43,9 @@ wxPython is a GUI toolkit for the Python programming language. It
|
||||
allows Python programmers to create programs with a robust, highly
|
||||
functional graphical user interface, simply and easily. It is
|
||||
implemented as a Python extension module (native code) that wraps the
|
||||
popular wxWindows cross platform GUI library, which is written in C++.
|
||||
popular wxWidgets cross platform GUI library, which is written in C++.
|
||||
|
||||
Like Python and wxWindows, wxPython is Open Source, which means that
|
||||
Like Python and wxWidgets, wxPython is Open Source, which means that
|
||||
it is free for anyone to use and the source code is available for
|
||||
anyone to look at and modify. And anyone can contribute fixes or
|
||||
enhnacments to the project.
|
||||
@ -86,15 +86,15 @@ Mac OS X
|
||||
* At least ?? MB of disk space.
|
||||
|
||||
|
||||
What is wxWindows?
|
||||
What is wxWidgets?
|
||||
==================
|
||||
|
||||
wxWindows is a C++ framework providing GUI (Graphical User Interface)
|
||||
wxWidgets is a C++ framework providing GUI (Graphical User Interface)
|
||||
and other facilities on more than one platform. Version 2 currently
|
||||
supports all desktop versions of MS Windows, Unix with GTK+, Unix with
|
||||
Motif, and MacOS. An OS/2 port is in progress.
|
||||
|
||||
wxWindows was originally developed at the Artificial Intelligence
|
||||
wxWidgets was originally developed at the Artificial Intelligence
|
||||
Applications Institute, University of Edinburgh, for internal use, and
|
||||
was first made publicly available in 1992. Version 2 is a vastly
|
||||
improved version written and maintained by Julian Smart, Robert
|
||||
@ -108,7 +108,7 @@ variants, unless otherwise stated. All trademarks are acknowledged.
|
||||
Why another cross-platform development tool?
|
||||
============================================
|
||||
|
||||
wxWindows was developed to provide a cheap and flexible way to
|
||||
wxWidgets was developed to provide a cheap and flexible way to
|
||||
maximize investment in GUI application development. While a number of
|
||||
commercial class libraries already existed for cross-platform
|
||||
development, none met all of the following criteria:
|
||||
@ -118,14 +118,14 @@ development, none met all of the following criteria:
|
||||
* simplicity of programming
|
||||
* support for a wide range of compilers
|
||||
|
||||
Since wxWindows was started, several other free or almost-free GUI
|
||||
Since wxWidgets was started, several other free or almost-free GUI
|
||||
frameworks have emerged. However, none has the range of features,
|
||||
flexibility, documentation and the well-established development team
|
||||
that wxWindows has.
|
||||
that wxWidgets has.
|
||||
|
||||
As open source software, wxWindows has benefited from comments, ideas,
|
||||
As open source software, wxWidgets has benefited from comments, ideas,
|
||||
bug fixes, enhancements and the sheer enthusiasm of users. This gives
|
||||
wxWindows a certain advantage over its commercial competitors (and
|
||||
wxWidgets a certain advantage over its commercial competitors (and
|
||||
over free libraries without an independent development team), plus a
|
||||
robustness against the transience of one individual or company. This
|
||||
openness and availability of source code is especially important when
|
||||
@ -141,17 +141,17 @@ The importance of using a platform-independent class library cannot be
|
||||
overstated, since GUI application development is very time-consuming,
|
||||
and sustained popularity of particular GUIs cannot be guaranteed.
|
||||
Code can very quickly become obsolete if it addresses the wrong
|
||||
platform or audience. wxWindows helps to insulate the programmer from
|
||||
these winds of change. Although wxWindows may not be suitable for
|
||||
platform or audience. wxWidgets helps to insulate the programmer from
|
||||
these winds of change. Although wxWidgets may not be suitable for
|
||||
every application (such as an OLE-intensive program), it provides
|
||||
access to most of the functionality a GUI program normally requires,
|
||||
plus many extras such as network programming, PostScript output, and
|
||||
HTML rendering; and it can of course be extended as needs dictate. As
|
||||
a bonus, it provides a far cleaner and easier programming interface
|
||||
than the native APIs. Programmers may find it worthwhile to use
|
||||
wxWindows even if they are developing on only one platform.
|
||||
wxWidgets even if they are developing on only one platform.
|
||||
|
||||
It is impossible to sum up the functionality of wxWindows in a few
|
||||
It is impossible to sum up the functionality of wxWidgets in a few
|
||||
paragraphs, but here are some of the benefits:
|
||||
|
||||
* Low cost (free, in fact!)
|
||||
@ -232,10 +232,10 @@ Help.
|
||||
GUI applications aren't all graphical wizardry. You'll also need
|
||||
lists and hash tables. But since you're working with Python, you
|
||||
should use the ones Python provides (list, tuple, dict), rather than
|
||||
the wxWindows versions. Same goes for the database related classes.
|
||||
the wxWidgets versions. Same goes for the database related classes.
|
||||
The basic rule of thumb is this: If you can do it directly in Python,
|
||||
you probably should. If there is a reason not to use a Python data
|
||||
type, wxPython will provide a wrapper for the wxWindows class.
|
||||
type, wxPython will provide a wrapper for the wxWidgets class.
|
||||
|
||||
You will undoubtedly need some platform-independent file functions,
|
||||
and you may find it handy to maintain and search a list of paths using
|
||||
@ -248,7 +248,7 @@ See also Classes by Category for a list of classes.
|
||||
Utilities and libraries supplied with wxPython
|
||||
==============================================
|
||||
|
||||
In addition to the core wxWindows library, a number of further
|
||||
In addition to the core wxWidgets library, a number of further
|
||||
libraries and utilities are supplied with each distribution.
|
||||
|
||||
[Need to list these.]
|
||||
@ -265,14 +265,14 @@ Creating and deleting wxPython objects
|
||||
so you don't need to delete these descendants explicitly.
|
||||
|
||||
.. When deleting a frame or dialog, use Destroy rather than delete so
|
||||
that the wxWindows delayed deletion can take effect. This waits
|
||||
that the wxWidgets delayed deletion can take effect. This waits
|
||||
until idle time (when all messages have been processed) to actually
|
||||
delete the window, to avoid problems associated with the GUI
|
||||
sending events to deleted windows.
|
||||
|
||||
.. If you decide to allocate a C++ array of objects (such as wxBitmap)
|
||||
that may be cleaned up by wxWindows, make sure you delete the array
|
||||
explicitly before wxWindows has a chance to do so on exit, since
|
||||
that may be cleaned up by wxWidgets, make sure you delete the array
|
||||
explicitly before wxWidgets has a chance to do so on exit, since
|
||||
calling delete on array members will cause memory problems.
|
||||
|
||||
.. wxColour can be created statically: it is not automatically cleaned
|
||||
@ -1002,7 +1002,7 @@ Submitting changes to the source document
|
||||
|
||||
Some items in the source text file look like this::
|
||||
|
||||
.. This is text from the wxWindows documentation that needs to be
|
||||
.. This is text from the wxWidgets documentation that needs to be
|
||||
translated into something appropriate for the wxPython version.
|
||||
The two dots followed by uniformly indented text turns this
|
||||
paragraph into a reStructuredText comment, so it doesn't appear
|
||||
@ -1033,7 +1033,7 @@ name):
|
||||
License
|
||||
=======
|
||||
|
||||
This document began as a translation of the wxWindows documentation.
|
||||
This document began as a translation of the wxWidgets documentation.
|
||||
As such, it adheres to the same license, which is provided here:
|
||||
|
||||
.. include:: ../licence/licendoc.txt
|
||||
|
@ -13,7 +13,8 @@ class MyFrame(wx.Frame):
|
||||
and has a simple menu.
|
||||
"""
|
||||
def __init__(self, parent, title):
|
||||
wx.Frame.__init__(self, parent, -1, title, size=(350, 200))
|
||||
wx.Frame.__init__(self, parent, -1, title,
|
||||
pos=(150, 150), size=(350, 200))
|
||||
|
||||
# Create the menubar
|
||||
menuBar = wx.MenuBar()
|
||||
@ -70,8 +71,13 @@ class MyFrame(wx.Frame):
|
||||
print "Having fun yet?"
|
||||
|
||||
|
||||
app = wx.PySimpleApp()
|
||||
frame = MyFrame(None, "Simple wxPython App")
|
||||
frame.Show(True)
|
||||
class MyApp(wx.App):
|
||||
def OnInit(self):
|
||||
frame = MyFrame(None, "Simple wxPython App")
|
||||
frame.Show(True)
|
||||
self.SetTopWindow(frame)
|
||||
return True
|
||||
|
||||
app = MyApp(True)
|
||||
app.MainLoop()
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user