PyGUI as a standard GUI API for Python?

Diez B. Roggisch deets at nospam.web.de
Wed Sep 3 15:25:48 EDT 2008


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



More information about the Python-list mailing list