++ +Again, we start with ResEdit to create our dialogs. Not only do we +want a main dialog this time but also an "About" dialog. This example is less +than complete since we do not provide a BNDL resource +and related stuff that an application cannot be without. We are able to do this +when building a python applet since BuildApplet will substitute default resources +for BNDL, etc. when none are supplied (See below.) +"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.
+ +When creating your own BNDL resouorces, keep in mind that the Finder gets +confused if you have more than one application with the same signature. This may be due +to some incorrectness on the side of "BuildApplet", 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.
+ +Let's have a look at dnslookup-2.rsrc, our resource file. Dialog 512 is the +main window which has one button (Lookup), two labels and +two text entry areas, one of which is used for output only. The "Quit" +button has disappeared, because its function is handled by a menu choice. Here's +what it will look like at run time:
+
++ +
FrameWork 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. + +
+If you have not used FrameWork before you may want to
+first take a look at the Pathetic EDitor
+example, which builds a minimal text editor using FrameWork and TextEdit.
+On the other hand: we don't use many features of FrameWork, so you could
+also continue with this document.
+
+
+After the imports we get the definitions of resource-IDs in our
+resource file, slightly changed from the previous version of our
+program. 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.
+
+Next comes the definition of our main class,
+DNSLookup, which inherits
+FrameWork.Application. The Application class handles the
+menu bar and the main event loop and event dispatching. In the
+__init__ 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 we call self._quit,
+which we will do when the user selects "Quit". When we create
+the instance of MyDialog (which inherits
+DialogWindow, which inherits Window) 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.
+
+The makeusermenus() method (which is called sometime
+during the Application __init__ routine) creates a File
+menu with a Quit command (shortcut command-Q), which will callback to
+our quit() method. Quit(), in turn, calls _quit which
+causes the mainloop to terminate at a convenient time.
+
+Application provides a standard about box, but we override this by
+providing our own do_about() 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.
+
+The MyDialog class is the container for our main
+window. Initialization is again done by first calling the base class
+__init__ function and finally setting the local variable
+"parent."
+
+Do_itemhit() 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. Dnslookup() is quite similar to our previous
+example.
+ +
Creating applets+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 and create true standalone +applications in Python, but this is a bit difficult. See +Standalone Applications in Python for details. For this +document, 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. ++ +The easiest way to create an applet is to take your source file and +drop it onto "BuildApplet", 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 'Pyt0'. The latter +also happens if you do have a resource file but without the BNDL +combo. Actually, as in the present example. +
+ +If you need slightly more control over the BuildApplet process you can +double-click it, 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.
+ +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.
+ +That's all for this example, you may now return to the +table of contents to pick another topic.
+ +