[Anygui-devel] Some import magic checked in

[Magnus L. H. <ml...@id...>]

Hi!

I've made a first attempt at implementing some import
magic for anygui (found in the anygui cvs repository).
Basically, the structure of the package is (currently)
as follows:

  anygui/
    |
    +--- __init__.py
    |
    +--- impl/
           |
           +--- __init__.py
           |
           +--- wxgui.py
           |
           +--- tkgui.py
           |
           +--- ...

The __init__ of the impl directory currently does
nothing (and could probably have been omitted, since
the impl module cannot be imported directly anytay...
See below.)

The various *gui.py files (currently only wxgui.py
and tkgui.py) are (as one might guess) meant tom contain
implementations for the various backends. In addition
to implementing the GUI API they should also provide
a (module-)global boolean variable called "viable",
which indicates whether the backend is viable in the
current Python system. This is used by anygui when
choosing a backend.

In the current version only wxgui.py and tkgui.py exist,
and they only contain dummy implementations of a class
called Window, meant to demonstrate the import mechanism.

The main magic is in the anygui/__init__.py file.
It installs an instance of the class "anygui" instead
of the module (thanks to Alex for this nifty trick).
This makes it possible to intercept module access
through __getattr__. The reason for this is that I
wanted to delay the choice of backend until the user
has had his or her say in the matter. In a way one
might say that the choice of backend is 'lazy' --
it is done at the point where it is needed, where
something is actually imported or used from the
anygui module.

*Before* this happens, the user may set an attribute
in anygui called "wishlist", containing a prioritized
list of backend names. These will be tried (in order)
before any other backends that may exist. If no
wish list is supplied, the default backend list is
used without modification. Some more intelligence
might be needed there -- at the very least some
intelligent ordering of the backends is needed...
The current ordering is:

  1. msw:  Microsoft Windows native
  2. x:    X-Windows native
  3. mac:  Macintosh native
  4. wx:   wxPython
  5. tk:   Tkinter
  6. java: Java

Both abbreviations and backend-selections were just
made off the top of my head. This is more a proof
of concept than anything... :)

Of course, since I only included (dummy) backends for
wx and tk, the others will fail (i.e. not be used).

OK. Enough talk. Here are two examples -- one using
the default order, and one providing a wishlist:

>>> from anygui import *
>>> w = Window('Hello, world!')
>>> w
<C wxFrame instance at _dd0ce8_wxFrame_p>

>>> import anygui
>>> anygui.wishlist = ['tk', 'java', 'mac']
>>> from anygui import *
>>> w = Window('Hello, world!')
>>> w
<tkgui.Window instance at 00DD7EBC>

Now, already in these simple tests I noticed a problem...
It seems that making a Tk window withoug showing it
isn't trivial. (Or it may be trivial -- I'm not really
an expert ;) So these two examples don't behave exactly
the same -- the first produces a hidden window, while
the second opens a Tk main window. Well, well. I'm
sure we'll be able to tackle that.

And another thing... To find the backend modules, I'm
using the traceback module (quite hackish... Any better
ways?) It seems that this doesn't quite work in
Jython 2.1a1 -- that's why I didn't include a javagui.py
for now. (I've submitted a bug-report to the Jython
crew.)

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick