Python and GUI

[rzed]

Brian Blais <bblais at bryant.edu> wrote in
news:mailman.8119.1180016569.32031.python-list at python.org: 

[...]

> Finally, consider wax (http://zephyrfalcon.org/labs/wax.html). 
> In my view, this is *exactly* what python needs, and its not
> being maintained anymore as far as I can tell.  What I like
> about it is: 
> 
> 1) it is small...I can include the entire wax distribution in my
> app with only a 780k 
>   footprint.
> 2) it is a very thin layer on wx, so when something doesn't
> quite work, I can immediately fall back onto wx, mixing and
> matching wax and wx objects.  it's just that the wax objects
> have more pythonic calling and use properties 
> 
> 
> Is there a reason that the port of wxPython doesn't include wax,
> or something similar?  It would seem pretty straightforward,
> when porting the wx to Python, to simply include such a wrapper.
>  I wish I were more clever, and had more time, to take over the
> maintenance of wax because I think it is the most
> straightforward, practical, and pythonic solution out there.
> 
> 
> Do others think like me here?
> 

I certainly do. Whether wax is the particular solution or not, 
something very like it should be. Something like this was tried at 
one time (Anygui) and the general consensus seems to be that it 
doesn't work as an approach because the packages are too 
different. I think that it's past time to revisit that conclusion. 

It would be very useful to a user of the Language we call Python 
to be able to write GUI code without regard to the back-end 
package. If there were a standard Python GUI API (call it the PGA, 
say) that be the target for app developers, they wouldn't have to 
worry about the back end. The PGA would have to be flexible enough 
to handle incompatibilities among the various approaches to 
displaying widgets and text. In order for that to happen, some 
kind of meeting of minds (among those who now deal with the murky 
middle between gui packages and python) would have to take place. 
A standard would have to be hammered out and then used. 

The standard would have to allow for generic calls for tasks that 
any reasonable GUI would have to handle. It would also have to 
provide for system-specific calls for those things that each 
package might require uniquely. The interface to the system-
specific stuff should itself be the same regardless of the back 
end. What I mean by this is that, where wax's limitations are 
overcome by dropping to wx directly, there should instead by a PGA 
winsys() call that permits passing command strings, values, or 
whatever in a dict-like object that would be permit the pga2wx 
interface to create the specific calls it needs. When the back end 
changes to Qt, the pga2Qt interface would make the translation 
instead. The code from the app programmer should not have to 
change, except maybe to add another item or items to the winsys 
dict.

I also think there should something similar for an interface for 
Python database access (PDBA). Anydb might not be the solution, 
but it could be. It would take cleverness (which abounds in the 
Python community),  determination (which may not be in such 
abundance) and project coordination for either of these projects 
to come to fruition. A summer of code kind of thing would provide 
a good initial push, and some sprints could move things along at a 
good clip. Wax, anygui, and anydb seem to be acceptable starting 
points, but the key thing is to get agreement from key players 
(like the developers of wxPython, dabo, PythonCard, and so on) to 
agree that this is a good direction to go in, and to try to work 
out the requirements for a flexible PGA and PDBA. I'm sure that 
the approach could produce usable results in short order, and then 
attack the remaining limitations over time.

Do I think this is going to happen? No. 

There are two overlapping things we call Python: the Language and 
the Package. The Language comes from Guido and a few others, but 
the Package comes from many sources, mostly volunteers. The GUI 
interfaces come from many such sources, each with a different view 
of what constitutes a good Pythonic interface. Having put a lot of 
time and effort into getting their version up and running, they're 
not about to change for some abstract reason, but nonetheless, I 
do believe that the Language of Python should have a GUI API 
defined, and that the Package of Python should accommodate to 
that. Unless that happens, we'll see more of what we now see: 
continual questions about what is the best GUI or the best 
Database. Because once you start building an app, you commit to 
the syntax of the package and you are no longer (in my view) 
coding in Python, but in that subset that includes the GUI Package 
of your choice.

-- 
rzed