diff options
| author | Jack Jansen <jack.jansen@cwi.nl> | 1996-03-18 13:38:52 (GMT) |
|---|---|---|
| committer | Jack Jansen <jack.jansen@cwi.nl> | 1996-03-18 13:38:52 (GMT) |
| commit | a6308130bb9e130ec532e05a2784e170584a5ac7 (patch) | |
| tree | b85ff85f71045522a37067d013067082ce497b2b /Mac/Demo/example2.html | |
| parent | f4875af09c1c2dc2ad76329560ce4345b0fe4cd9 (diff) | |
| download | cpython-a6308130bb9e130ec532e05a2784e170584a5ac7.zip cpython-a6308130bb9e130ec532e05a2784e170584a5ac7.tar.gz cpython-a6308130bb9e130ec532e05a2784e170584a5ac7.tar.bz2 | |
Explanations of the examples here
Diffstat (limited to 'Mac/Demo/example2.html')
| -rw-r--r-- | Mac/Demo/example2.html | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/Mac/Demo/example2.html b/Mac/Demo/example2.html new file mode 100644 index 0000000..3bd2791 --- /dev/null +++ b/Mac/Demo/example2.html @@ -0,0 +1,180 @@ +<HTML><HEAD><TITLE>Using python to create Macintosh applications, part two</TITLE></HEAD> +<BODY> +<H1>Using python to create Macintosh applications, part two</H1> +<HR> + +In this document we rewrite the application of the <A +HREF="example1.html">previous example</A> to use modeless dialogs. We +will use an application framework, and we will have a look at creating +applets, standalone applications written in Python. <A +HREF="example2/InterslipControl-2.py">Source</A> and resource file (in +binary and <A HREF="example2/InterslipControl-2.rsrc.hqx">BinHex</A> +form for downloading) are available in the folder <A +HREF="example2">example2</A>. If you want to run the program on your +machine you will also need a new copy of <A +HREF="update-to-1.3/FrameWork.py">FrameWork.py</A>, which has been +updated since the 1.3 release. <p> + +Again, we start with ResEdit to create our dialogs. Not only do we +want a main dialog this time but also an "About" dialog, and we +provide the <A NAME="bundle">BNDL resource</A> and related stuff that +an application cannot be without. (Actually, a python applet can be +without, <A HREF="#no-bundle">see below</A>). "Inside Mac" or various +books on macintosh programming will help here. Also, you can refer to +the resource files provided in the Python source distribution for some +of the python-specific points of BNDL programming: the +"appletbundle.rsrc" file is what is used for creating applets if you +don't provide your own resource file. <p> + +Let's have a look at InterslipControl-2.rsrc, our resource file. First +off, there's the standard BNDL combo. I've picked 'PYTi' as signature +for the application. I tend to pick PYT plus one lower-case letter for +my signatures. The finder gets confused if you have two applications +with the same signature. This may be due to some incorrectness on the +side of "mkapplet", I am not sure. There is one case when you +definitely need a unique signature: when you create an applet that has +its own data files and you want the user to be able to start your +applet by double-clicking one of the datafiles. <p> + +There's little to tell about the BNDL stuff: I basically copied the +generic Python applet icons and pasted in the symbol for +InterSLIP. The two dialogs are equally unexciting: dialog 512 is our +main window which has four static text fields (two of which we will be +modifying during runtime, to show the status of the connection) and +two buttons "connect" and "disconnect". The "quit" and "update status" +buttons have disappeared, because they are handled by a menu choice +and automatically, respectively. <p> + +<H2>A modeless dialog application using FrameWork</H2> + +On to the source code in <A +HREF="example2/InterslipControl-2.py">InterslipControl-2.py</A>. The +start is similar to our previous example program <A +HREF="example1/InterslipControl-1.py">InterSlipControl-1.py</A>, with +one extra module being imported. To make life more simple we will use +the <CODE>FrameWork</CODE> module, a nifty piece of code that handles +all the gory mac details of event loop programming, menubar +installation and all the other code that is the same for every mac +program in the world. Like most standard modules, FrameWork will run +some sample test code when you invoke it as a main program, so try it +now. It will create a menu bar with an Apple menu with the about box +and a "File" menu with some pythonesque choices (which do nothing +interesting, by the way) and a "Quit" command that works. <p> + +<CITE> +A more complete description of <A NAME="framework">FrameWork</A> is +sorely needed, and will (at some point) be incorporated in the +programmers manual or in place of this paragraph. For now you'll have +to make do with the knowledge that you use FrameWork by building your +classes upon the classes provided by it and selectively overriding +methods to extend its functionality (or override the default +behaviour). And you should read the Source, of Course:-) <p> +</CITE> + +After the imports we get the definitions of resource-IDs in our +resource file, slightly changed from the previous version of our +program, and the state to string mapping. The main program is also +similar to our previous version, with one important exception: we +first check to see whether our resource is available before opening +the resource file. Why is this? Because later, when we will have +converted the script to an applet, our resources will be available in +the applet file and we don't need the separate resource file +anymore. <p> + +Next comes the definition of our main class, +<CODE>InterslipControl</CODE>, which inherits +<CODE>FrameWork.Application</CODE>. The Application class handles the +menu bar and the main event loop and event dispatching. In the +<CODE>__init__</CODE> routine we first let the base class initialize +itself, then we create our modeless dialog and finally we jump into +the main loop. The main loop continues until <CODE>self</CODE> is +raised, which we will do when the user selects "quit". When we create +the instance of <CODE>MyDialog</CODE> (which inherits +<CODE>DialogWindow</CODE>, which inherits <CODE>Window</CODE>) we pass +a reference to the application object, this reference is used to tell +Application about our new window. This enables the event loop to keep +track of all windows and dispatch things like update events and mouse +clicks. <p> + +The <CODE>makeusermenus()</CODE> method (which is called sometime +during the Application <CODE>__init__</CODE> routine) creates a File +menu with a Quit command (shortcut command-Q), which will callback to +our quit() method. <CODE>Quit()</CODE>, in turn, raises 'self' which +causes the mainloop to terminate. <p> + +Application provides a standard about box, but we override this by +providing our own <CODE>do_about()</CODE> method which shows an about +box from a resource as a modal dialog. This piece of code should look +familiar to you from the previous example program. That do_about is +called when the user selects About from the Apple menu is, again, +taken care of by the __init__ routine of Application. <p> + +Our main object finally overrides <CODE>idle()</CODE>, the method +called when no event is available. It passes the call on to our dialog +object to give it a chance to update the status fields, if needed. <p> + +The <CODE>MyDialog</CODE> class is the container for our main +window. Initialization is again done by first calling the base class +<CODE>__init__</CODE> function and finally setting two local variables +that are used by <CODE>updatestatus()</CODE> later. <p> + +<CODE>Do_itemhit()</CODE> is called when an item is selected in this +dialog by the user. We are passed the item number (and the original +event structure, which we normally ignore). The code is similar to the +main loop of our previous example program: a switch depending on the +item selected. <CODE>Connect()</CODE> and <CODE>disconnect()</CODE> +are again quite similar to our previous example. <p> + +<CODE>Updatestatus()</CODE> is different, however. It is now +potentially called many times per second instead of only when the +user presses a button we don't want to update the display every time +since that would cause some quite horrible flashing. Luckily, +<CODE>interslip.status()</CODE> not only provides us with a state and +a message but also with a message sequence number. If neither state +nor message sequence number has changed since the last call there is +no need to update the display, so we just return. For the rest, +nothing has changed. <p> + +<H2><IMG SRC="html.icons/mkapplet.gif"><A NAME="applets">Creating applets</A></H2> + +Now, if you have a PowerPC Macintosh, let us try to turn the python +script into an applet, a standalone application. Actually, +"standalone" is probably not the correct term here, since an applet +does still depend on a lot of the python environment: the PythonCore +shared library, the Python Preferences file, the python Lib folder and +any other modules that the main module depends on. It is possible to +get rid of all these dependencies except for the dependency on +PythonCore, but at the moment that is still quite difficult so we will +ignore that possibility for now. By standalone we mean here that the +script has the look-and-feel of an application, including the ability +to have its own document types, be droppable, etc. <p> + +The easiest way to create an applet is to take your source file and +drop it onto "mkapplet" (normally located in the Python home +folder). This will create an applet with the same name as your python +source with the ".py" stripped. Also, if a resource file with the same +name as your source but with ".rsrc" extension is available the +resources from that file will be copied to your applet too. If there +is no resource file for your script a set of default resources will be +used, and the applet will have the default creator 'PYTa'. The latter +also happens if you do have a resource file but without the BNDL +combo. <A NAME="no-bundle">Actually</A>, for our example that would +have been the most logical solution, since our applet does not have +its own data files. It would have saved us hunting for an unused +creator code. The only reason for using the BNDL in this case is +having the custom icon, but that could have been done by pasting an +icon on the finder Info window, or by providing an custon icon in your +resource file and setting the "custom icon" finder bit. <p> + +If you need slightly more control over the mkapplet process you can +double-click mkapplet, and you will get dialogs for source and +destination of the applet. The rest of the process, including locating +the resource file, remains the same. <p> + +Note that though our example application completely bypasses the +normal python user interface this is by no means necessary. Any python +script can be turned into an applet, and all the usual features of the +interpreter still work. <p> + +That's all for this example, you may now return to the <A HREF="index.html"> +table of contents</A> to pick another topic. <p> |