[Pythonmac-SIG] A W backend for anygui

[Chris Barker]

Larry Meyn wrote:
> I recently came across a notice about the "anygui" project at source forge, http://anygui.sourceforge.net/, which is trying to create a generic Python GUI interface to several existing GUI packages.

This is entirely just my not-the-least-bit-humble opinion, and I wish
the anygui folks the best of luck, but I really think it is a dead end.
Trying to write a single interface to a wide variety of GUI libraries is
very difficult because each of those libraries has a different set of
widgets, different behaviour, and different event models. The only way
to accomidate all that is to have a very thick wrapper that either:

targets the least common denominator: only those things all the targeted
back ends support

or

targets the super-set: all the things that are supported by any
individual back end, in which case you have to write emulation code for
each back end for each feature it doesn't support.

The downside of the second option is two-fold: It is a lot of work, and
you are likely to have major performance problems if it's all in Python.

Another issue I see is that the final result will be a wrapper around a
wrapper, around a wrapper, etc like this:

anygui -> tkinter -> tcl -> tk -> Win32 | X | MacToolbox

or 

anygui -> wxPython -> wxWindows -> Win32 | GTK | ...

My question is: what's the point? People have a lot of need to write one
program that will run on multiple platforms, and with multiple
look&feels, but why would you want multiple toolkits? The reason I
choose one toolkit over another is a combination of supported platforms,
supported features, and how much I like the API. If someone comes up
with a toolkit that supports all the platforms I want, has the features
I need, with a nice API, I will want to use it. I couldn't care less
what the back end is.

If successfull, the anyGUI project will create a nice API and a complete
feature set, and it will run on numerous platforms. This is good, but
when I look at this:

The currently planned list of backend interfaces includes:
> 
> BeOS native
> Dynamic HTML
> Java Swing
> PythonWin/win32all
> PyGTK
> Tkinter
> wxPython
> PyQt
> Curses

I wonder why you would you need to support wxPython if you are
supporting GTK, Win32, and hopefully MacOS in one form or another. Being
able to support DHTML and Curses would be nice, but you simply can't
write a rich GUI in those, so I wonder what they have in mind.
Supporting JAVA/SWING is nice too, so if they can really make this work,
that might be a plus.

Anyway, this is why my money is on wxPython: It is not quite complete
(particularly on the Mac), but neither is anyGUI. Essentially, the goal
of wxWindows is similar to the anygui project, but in C++. This is a
good thing, because it eliminates one layer of wrappers, and has
significant perfomance advantages. If it continues on its present course
is will meet all of my requirements:

Supports the platforms I need: Win32, *nix (GTK | Motif), OS/2, Mac
Classic and OS-X
Has the features I need: A pretty rich set, with more to come, and
pretty good performance.
A nice API: Well, honestly, this is its weakest link. The wxPython
wrappers are fairly thin wrappers around the C++, so the API is very
similar. This is three advantages:

1) It is easier to do, with SWIG doing most of the work (Robin never
would have gotten it to where it is without taking that approach).

2) The wxWindows docs and wxPtyhon docs are merged. Without that, would
barely have wxPython docs.

3) If you are using Python as a prototyping language, you can later
translate some or all of your GUI code from Python to C++ without
changing the structure at all.

There is hope on the API front as well. Kevin Altis has begun a project
to write a thicker wrapper layer around wxWindows, so that Python users
can have a more Pythonesque interface. We'll see where this project
goes, but it has a lot of promise.

Another problem with wrappers around wrappers is that there is a large
chain of different projects that you are dependent on. Right now,
wxPython depends on Python and wxWindows. Python is as wonderful as we
all know it is, and wxWindows is being actively developed and supported,
and the developers are supportive of Python.

Right now there is no good framework for writing cross-platform apps
that include the Mac. I really think we need one, and I'm convinced that
wxPython is the best option at this point. It is absolutely closest to
what is needed.

> It seems like an anygui backend for the W package could solve some cross-platform GUI needs.  Is there anyone around with the time and expertise to do this?  Or is this even worth doing right now?

You now know my answer to whether it is worth it, so I encourage anyone
with the time and expertise to contribute to the wxPython project
instead.

OK, I'm done with my rant now....

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker@home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------