Removed most of the README text since it is all about the Mac specific

examples, which no longer live here.

1 files changed, 5 insertions, 161 deletions

diff --git a/Tools/bgen/README b/Tools/bgen/README
index 38d3ad6..70700c6 100644
--- a/Tools/bgen/README
+++ b/Tools/bgen/README
@@ -1,163 +1,7 @@
-BGEN -- An Experiment: Automatic Generation of Extension Modules
-================================================================
+BGEN -- Automatic Generation of Extension Modules
+=================================================
 
 This directory contains BGEN -- a package that helps in generating
-complete source code for Python extension module.  It currently also
-contains a set of examples that were generated with BGEN.  These
-examples are mostly interfaces to a number of important managers in
-the Macintosh toolbox.
-
-
-Overview of Subdirectories
---------------------------
-
-Main subdirectories:
-
-bgen	the code generator package
-
-Example subdirectories:
-
-ae	AppleEvents
-ctl	Controls
-cm	Component manager
-dlg	Dialogs
-evt	Events
-menu	Menus
-list	Lists
-qd	QuickDraw
-qt	QuickTime
-res	Resources
-snd	Sound
-win	Windows
-
-
-Contents of Subdirectories
---------------------------
-
-The contents of each example subdirectory is similar (<Foobar> is
-for instance AppleEvents, while <foo> is ae):
-
-<foo>scan.py	Scan the <Foobar>.h header, generating <foo>gen.py
-<foo>gen.py	Output of <foo>scan.py, input for <foo>support.py
-<foo>edit.py	Manually written complement of <foo>gen.py, sometimes
-<foo>support.py	Generate <Foo>module.c from <foo>gen.py and <foo>edit.py
-<Foo>module.c	The interface module, ready to be compiled
-<Foobar>.py	Symbolic constants extracted from <Foobar.h>
-
-
-Tests and Examples
-------------------
-
-Other files in these subdirectories are usually examples using the
-extension.  If there's a file t<foo>.py, it usually is a really
-boring test program.
-
-Some test programs contain pathnames that should be edited before
-trying them.
-
-Some of the less boring tests and examples:
-
-At the top level:
-
-test.py		Application mainloop, uses most Mac extensions
-
-In ae:
-
-aetools.py	Conversions between AE and Python data type
-echo.py		Dummy AE server, echoes all data back
-tell.py		Primitive AE client
-aete.py		Decode 'aete' and 'aeut' resources (incomplete)
-gensuitemodule.py
-		Read aete/aeut resources and turn them into python
-		modules. The *_Suite.py modules have been generated
-		with this.
-AEservertest.py	A simple AE server, similar to echo but different.
-
-In cm:
-cmtest.py	List all components in the system plus some info on them
-
-In qt:
-MovieInWindow.py	Play a movie in a fixed-sized window, stop on mouse-press
-VerySimplePlayer.py	Play a movie with the standard quicktime controller.
-
-In res:
-
-listres.py	List *all* resources in current and in all res files
-copyres.py	Copy a resource file
-mkerrstrres.py	Read "errors.txt" and create a set of "Estr" resources
-
-In snd:
-
-playaiff.py	Play an AIFF file
-morse.py	Turn text into Morse code
-audiodev.py	The standard audiodev.py extended with Mac support
-Audio_mac.py	The Mac support for audiodev.py
-
-
-Creating new Macintosh interfaces
----------------------------------
-
-These instructions were written up by Jack while he was building the
-interface to Lists.h, the macintosh list manager. they may or may not
-have a more global scope than exactly that.
-
-First, start by copying ...scan.py and ...support.py from another,
-preferrably similar type. I started with evt, but that was a mistake
-since evt has no "own" object. Ctl or Dlg would probably have been a
-better idea.
-
-Now, the first thing to do is to comment out the blacklisted types and
-functions and the transformation rules for arguments, we'll fill those
-in lateron. Also, change the various definitions at the top, so that
-the right include file is parsed, and the .py files are generated with
-the correct name. If your manager has a type that will be implemented
-as a python object you may as well now change the destination() method
-to recognize that. (List was funny in this respect, since it has the
-list as the last argument in stead of the first).
-
-Now run your scanner. This will probably go fine until it tries to
-execute the generated code in the ...gen.py module. Look at that file,
-it will have formalized "definitions" of all the functions and methods
-that will be generated. Look at them all (with the documentation of the
-manager you're implementing in hand). Now you'll have to fix the
-blacklists and the repair instructions. This is sort of a black art,
-but a few guidelines may be handy here: 
-- If there are argument types you cannot implement (or want to leave for
-  the moment) put them in blacklisttypes. Complex structures come to
-  mind, or routine pointers/UPP's. You will probably also want to
-  blacklist the routine that disposes of your object (since you'll do
-  that in the python destruction routine).
-- Various types of buffers are available in bgenBuffer, bgenHeapBuffer
-  and macsupport in the bgen directory. These'll let you handle all
-  sorts of input and output parameters. You can put instructions in the
-  repair list to let the C-arguments be handled by the correct type
-  of buffer. Check the other bgen-generated modules for using this for
-  passing raw structures and input and output buffers.
-- It appears that the parser usually guesses correctly whether a parameter
-  is meant for input or output. But, check the routines to be sure.
-- Some types are pretty hard to handle but you need the functionality
-  the a routine that uses them anyway. Various routines expecting ProcPtrs
-  or RegionHandles come to mind. Often, you can use the FakeType class
-  to provide a sensible default (i.e. NULL or a pointer to a routine you
-  coded in C, or a region specifying "the whole window"). This way, python
-  programmers won't get the full functionality but at least they'll get the
-  common case. You put the FakeType stuff in ...support.py.
-  
-Next you'll probably have to write the code to implement your object.
-This will probably be a subclass of GlobalObjectDefinition. This goes
-into ...support.py. Also, some types used by the manager may look
-enough like standard types that you can equate them here (there are a
-lot of 2-integer structures that look remarkably like a Point, for
-instance).
-
-You'll also have to define the Function() and Method() classes. The
-OSErrFunctionGenerator and its method-counterpart are particularly
-handy for a lot of mac managers.
-
-Finally, you'll have to try and compile your resulting C-source, and go
-through the steps above until it works. For tlist.py, the test program
-for list, I started with the application framework. This is probably a
-good idea for any manager that does something to the display, since
-ApplicationFramework takes care of all the intricacies of event
-handling and decoding (up to a point).
-
+complete source code for Python extension module.  For examples of its
+use, see the Mac Python source distribution (available separately
+from the Python ftp archives).  Note that BGEN is not Mac specific!