Michael Palmer schrieb:
I disagree with that. Meta-wrappers like this will always suffer from
problems, as they have difficulties providing a consistent api. For
example wx is said to be very windows-toolkit-centric in it's API. Yes I
know that it works under Linux with GTK, but it does not come as natural .
wax actually does a nice job at wrapping wxPython with a cleaner API.
wax wraps wx. It does not wrap PyQt, Tk, win32, GTK and whatnot. That
was what I was talking about.
Right. But that is similar to the situation with relational databases.
There are so many of them that it's impossible to include an adapter
to each of them in the stdlib. The next best thing is to provide a
high-level API that abstracts away the differences.
As long as none of these is "the winner" (and it doesn't look is if that's
to happen soon), I doubt that one API to rule them all will exist - they
all have their different strengths and weaknesses, and a python-API
should reflect these.
I rather think that a standard API would cover a reasonable subset -
it should NOT contain the idiosyncrasies of each individual toolkit.
And thus reduce the usability massively. A reasonable subset is already
included in python, with tkinter, available on a wide range of plattforms.
Yet still people strive for the various other toolkits, because they
miss richer widgets, gui-designers (an important topic you don't cover
at all) or e.g. multi-threading capabilities.
The anygui project, which has been dormant for a while, is another
attempt at a high-level api. Apparently, it tried to implement
backends for a lot of toolkits - which again may have been to
ambitious an agenda. Maybe someone who was involved in that project
might provide some insight.
Sure, that would be interesting.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
