Comparioson of purpose for PyGUI and AnyGUI ???

[Chris Barker]

I can't help myself.

I havn't used either PyGUI or AnyGUI, but there is a reason:

PyGUI looks like a wonderful project, the kind of GUI framework that
should have come with Python ages ago. Let's face it, would TCL have
ANYTHING like it's current popularity if it hadn't been for TK? It
seems to me that AnyGUI is trying to be for Python what TK is for TCL,
a real, native toolkit makde to work well with the language.

However, it is going to take a LOT of work to get it to a point where
it is nearly as full featured as wxPython, PYGTK or PyQT (or even
TKinter, if you include all the extensions available for it). I can't
help wondering if the project would be better off leveraging a
existing cross-platform toolkit, maybe one lighter weight than wx,
like Fox or FLTK. Anyway, if the PyGUI folks (is anyone other than
Greg Ewing working on it?) can keep the momentum going, I'll certainly
switch when it supports the features I need. It does have one
development advantage over wxPython: any higher level widgets (grid,
canvas, etc) should be much easier to maintain, as they will be
written in Python, rather than C++.

One thing that isn't clear to me about PyGUI is how much they intend
to leverage the underlying toolkits. wxWidgets (and thus wxPython)
make use of a lot of higer level widgets like the tree controls, using
the native ones in  the underlying toolkits. This makes apps look very
native, but does create a very difficult problem in cross platform
compatibility. I wonder where in the native vs. cross platform
continuum PyGUI will fall...

We should all keep an eye on Wax and Pythoncard as well. Similar goals
to PyGUI, but taking a different approach, by leveraging the exisitng
wxPython framework. This gives them far more functionality, even when
they are immature, which is nice. I'd much rather do something in a
non-python way than not be able to do it at all!

Now AnyGUI:

I have always thought this was a mis-guided effort from the beginning.
"""
The purpose of the Anygui project is to create an easy-to-use, simple,
and generic module for making graphical user interfaces in Python. Its
main feature is that it works transparently with many different GUI
packages on most platforms.
"""

The first part is the same goal as PyGUI (and any number of other
projects). The second part, however, I just don't get. Who cares that
it will work with multiple toolkits underneith? When I'm selecting a
toolkit, aside from licensing issues, I consider:

* What platforms does it run on?

As long as it runs on the platforms I need, I'm happy. In my case,
that's OS-X, Linux and Windows.

* What is the "look and feel" (the users experience)?

I prefer to have a native look and feel. Some don't care so much.

* What is the API like (the programmers experience)?

I'd like it to be clean, and feel "pythonic"

* What features does it have? (how much code can I just use, rather
than have to write myself)

The TK Canvas, for instance, is a strong argument for TK. wx.Grid and
wx.STC likewise for wxPython.

As far as what is functioning today, that leaves wxPython and pyQT as
my options. I don't like the API of wxPython much, but it's C++ core
is in fact helpful to me. I work in a shop that is quite distrustful
of new fangled things like Python, but I have gotten them to use
wxWidgets with C++, and have some hope of moving some or all work to
wxPython. The fact that I can use the same toolkit with C++ and Python
is a big win for that.

Now back to AnyGUI: how is going to help with any of the above issues?
wxPython works on all the platforms I need, and has most of the
features I need. It has a pretty lousy API, so I'd like to see that
improve. However, AnyGUI, while it will likely provide a much more
Pythonic API, is introducing another requirement that is going to be a
real problem: it needs to work with lots of toolkits. This is going to
cause a balance between two competing problems:

1) lowest common denominator. If a feature doesn't exist on all
toolkits, AnyGUI can't have it.

or

2) emulating features on all the platforms that don't have them. This
is a Monsterous amount of work ,and may not even be practical without
resorting to C or C++. Can you imagine writing the wx.Grid in TK, GTK,
Swing, QT, curses!, FLTK, and who knows what else.

Another issue is layers:

AnyGUI wxPython is a python wrapper around a SWIG wrapper around a C++
wrapper around a set of native toolkits.

AnyGUI TKinter is a python wrapper around a python wrapper around a
TCL toolkit, written in C that emulates X on non-X platforms.

Doesn't this seem a bit much?

I'd much rather see the effort going into making wxPython more
pythonic (Wax or Pythoncard), or a truly python native toolkit, like
PyGUI

that's enough ranting for one night!

-Chris