PyGUI as a standard GUI API for Python?

[Michael Palmer]

As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.

I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.

So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.

I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.

Best, Michael

[Diez B. Roggisch]

Re: PyGUI as a standard GUI API for Python?

Michael Palmer schrieb:

As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.
>
I've come across two projects that have the appeal of striving for
simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
wxPython. It is lacking documentation but actually quite usable and
concise. The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.

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 .

So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.
>
I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.

I think you do. The reason for the various toolkits is not because of
python - it's the proliferation of toolkits that exist out there. 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.

Diez

[Michael Palmer]

Re: PyGUI as a standard GUI API for Python?

On Sep 3, 12:57 pm, "Diez B. Roggisch" <de...@nospam.w eb.dewrote:

Michael Palmer schrieb:
>

The other, PyGUI, has an even nicer API and more docs but has
relatively few widgets implemented at this time. It also strives for
compatibility with several toolkits (two at this time), which I think
is the right idea.

>
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.

So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation? This
might make it easier for people to contribute implementation code and
maybe port the API to additional toolkits. It seems that this approach
has been quite successful in case of the Python database API. That API
defines levels of compliance, which might be a way of accommodating
different GUI toolkits as well.

>

I may be underestimating the difficulties of my proposed approach - I
don't have much practical experience with GUI programming myself.

>
I think you do. The reason for the various toolkits is not because of
python - it's the proliferation of toolkits that exist out there.

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.

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.

[Diez B. Roggisch]

Re: PyGUI as a standard GUI API for Python?

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

[OKB (not okblacke)]

Re: PyGUI as a standard GUI API for Python?

Michael Palmer wrote:

As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.

How about Dabo? http://www.dabodev.com/


--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[Greg Ewing]

Re: PyGUI as a standard GUI API for Python?

Michael Palmer wrote:

So far, development of PyGUI seems to be a one-man effort, and it may
be slowed down by the attempt to develop the API and the
implementations concurrently. Could it be useful to uncouple the two,
such that the API would be specified ahead of the implementation?

I'm not sure that would work very well. I don't think
it's possible to invent a good API for something as
complex as a GUI toolkit in the absence of experience
using it, so the API has to evolve in parallel with at
least one implementation, and with real applications
that actually use the features concerned.

Also, the features that go into the PyGUI API are partly
determined by what is available in the underlying target
libraries. I don't want to end up with things in the
API specification that are too difficult or unwieldy
to implement on some of the target platforms. I also
don't want one implementation to get too far ahead of
the others, for the same reason.

If anyone wants to help, what's needed most right now
is a good native Windows implementation. One or two
people claimed to be working on that some time ago,
but I haven't heard from them recently. For the reasons
I mentioned above, I'm reluctant to forge ahead with
too many new features until a native Windows version
exists.

--
Greg

[Kay Schluehr]

Re: PyGUI as a standard GUI API for Python?

On 3 Sep., 18:34, Michael Palmer <m_palme...@yah oo.cawrote:

As anyone knows, the state of Python GUI programming is a little
fractured at this time, with many toolkits, wrappers and meta-wrappers
dead and alive, with or without documentation.

A few thoughts.

1) This topic is discussed here every few months. While some kind of
AnyGUI is theoretically very elegant it hasn't worked out well in
practice: GUI libs are huge and heterogeneous. It's much unlike
building an API-layer on top of SQL. Moreover I'd like to ask whether
the fragmentation turns out to be that much of a problem in practice?

2) Tcl/Tk might have a revival due to the new Tk-theme engine in
version 8.5.

http://www.tcl.tk/software/tcltk/8.5.tml

http://wiki.tcl.tk/13636

Chances are Tkinter widgets will not look like early '90s legacy
anymore.

3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.

Ciao, Kay

[M.-A. Lemburg]

Re: PyGUI as a standard GUI API for Python?

On 2008-09-04 07:49, Kay Schluehr wrote:

3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.

Actually, it has already and quite some time ago:

http://www.artima.com/weblogs/viewpost.jsp?thread=208528

The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.

As a nice side-effect, this also results in a better separation
between GUI and backend, effectively making the solution future-proof
and easy to adapt to other front-end technologies.

We've been working with this approach for almost a year now and
so far never had to look back.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Sep 04 2008)

>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>mxODBC.Zope.D atabase.Adapter ... http://zope.egenix.com/
>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

_______________ _______________ _______________ _______________ ____________

:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611

[Kay Schluehr]

Re: PyGUI as a standard GUI API for Python?

On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.co mwrote:

On 2008-09-04 07:49, Kay Schluehr wrote:
>

3) Following the public rumor mill and the latest hype RIA i.e. the
merge of web- and desktop applications with systems like Adobe AIR,
JavaFX, Google Gears and MS Silverlight is the future of frontend
development. With the exception of IronPython and Silverlight, Python
hasn't even entered this game and no one knows if it ever will.

>
Actually, it has already and quite some time ago:
>

http://www.artima.com/weblogs/viewpost.jsp?thread=208528

>
The recipe is simple: use Python for the business logic, database
interfacing, etc and have it talk to a Flex front-end via XML-RPC
or REST.

Python is still server-side in this scenario and plays no role in UI
definitions. So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML +Browser is replaced by Flex = AS3+MXML+FlashP layer.
The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.

About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...

[M.-A. Lemburg]

Re: PyGUI as a standard GUI API for Python?

On 2008-09-04 11:14, Kay Schluehr wrote:

On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.co mwrote:

>On 2008-09-04 07:49, Kay Schluehr wrote:
>>

>>3) Following the public rumor mill and the latest hype RIA i.e. the
>>merge of web- and desktop applications with systems like Adobe AIR,
>>JavaFX, Google Gears and MS Silverlight is the future of frontend
>>development . With the exception of IronPython and Silverlight, Python
>>hasn't even entered this game and no one knows if it ever will.

>Actually, it has already and quite some time ago:
>>
>http://www.artima.com/weblogs/viewpo...?thread=208528
>>
>The recipe is simple: use Python for the business logic, database
>interfacing, etc and have it talk to a Flex front-end via XML-RPC
>or REST.

>
Python is still server-side in this scenario and plays no role in UI
definitions.

That depends on how you design the application. It is well possible
to have Python drive the GUI by sending the required details to
the Flex front-end via XML (ie. data-driven GUIs).

So one doesn't get more than e.g. Django apps that
respond to HTTP requests triggered by JavaScript forms except that
JavaScript+HTML +Browser is replaced by Flex = AS3+MXML+FlashP layer.

You really can't compare the Flex stack to an AJAX stack. Flex
has a lot more to offer for GUI programming than AJAX, it also
doesn't suffer from the problems of AJAX having to support several
different sets of browser or library bugs.

We switched from an AJAX approach to a Flex-based approach last year
and never even considered moving back again.

The role of Python is somewhat arbitrary. This could change only if
Python becomes a client side language executed by AVM, V8 etc. like
IronPython in Silverlight.
>
About separating UI from application logics by assigning functionality
to different general purpose languages I have to admit that I don't
think it is such a great idea ...

In my experience, Flex + Python gives you the best of both worlds,
the nice GUI features of Flex and the efficiency of Python for the
business logic.

A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Sep 04 2008)

>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>mxODBC.Zope.D atabase.Adapter ... http://zope.egenix.com/
>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

_______________ _______________ _______________ _______________ ____________

:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611

[M.-A. Lemburg]

Re: PyGUI as a standard GUI API for Python?

On 2008-09-04 12:57, Banibrata Dutta wrote:

On Thu, Sep 4, 2008 at 3:45 PM, M.-A. Lemburg <mal@egenix.com wrote:
>

>On 2008-09-04 11:14, Kay Schluehr wrote:

>>On 4 Sep., 10:31, "M.-A. Lemburg" <m...@egenix.co mwrote:
>>>On 2008-09-04 07:49, Kay Schluehr wrote:
>>>>
>>>>3) Following the public rumor mill and the latest hype RIA i.e. the
>>>>merge of web- and desktop applications with systems like Adobe AIR,
>>>>JavaFX, Google Gears and MS Silverlight is the future of frontend
>>>>development . With the exception of IronPython and Silverlight, Python
>>>>hasn't even entered this game and no one knows if it ever will.
>>>Actually, it has already and quite some time ago:
>>>>
>>>http://www.artima.com/weblogs/viewpo...?thread=208528
>>>>
>>>The recipe is simple: use Python for the business logic, database
>>>interfacin g, etc and have it talk to a Flex front-end via XML-RPC
>>>or REST.
>>Python is still server-side in this scenario and plays no role in UI
>>definitions .

>That depends on how you design the application. It is well possible
>to have Python drive the GUI by sending the required details to
>the Flex front-end via XML (ie. data-driven GUIs).
>>

>>So one doesn't get more than e.g. Django apps that
>>respond to HTTP requests triggered by JavaScript forms except that
>>JavaScript+HT ML+Browser is replaced by Flex = AS3+MXML+FlashP layer.

>You really can't compare the Flex stack to an AJAX stack. Flex
>has a lot more to offer for GUI programming than AJAX, it also
>doesn't suffer from the problems of AJAX having to support several
>different sets of browser or library bugs.
>>
>We switched from an AJAX approach to a Flex-based approach last year
>and never even considered moving back again.

>
>
The approach does seem quite impressive, but isn't Flex's platform
neutrality quite over-rated ? I mean after-all, it assumes that Flex is
available for and available on the platform. Flex today is not yet so
ubiquitous as the JRE...

Since Flex is compiled to Flash and runs inside the Flash player, it
is fairly easy to get Flex apps running. You do have to have the
Flash9 player installed and the default minimum is 9.0.115.0 for
Flex builder 3.

Are there some established best-practices on how to package such
applications -- s.a. shipping with its's own Flex runtime, offer-download if
missing etc. ? What happens if owner of target machine decides to upgrade
their version of Flex, will it impact the application package in anyway, and
render rest of it "non-upgradable" ?

So far we have not had any such problems, but that could change when
Flash10 starts to ship, of course.

We currently ship the application as a server application. The only
requirement on the client side is having a browser with Flash9
installed. Pointing the browser at the server will then load the
compiled Flex application (as .swf file).

An alternative approach is bundling the client as AIR application
which then runs as stand-alone app on the client side, but we
haven't tried that yet.

>>The role of Python is somewhat arbitrary. This could change only if
>>Python becomes a client side language executed by AVM, V8 etc. like
>>IronPython in Silverlight.
>>>
>>About separating UI from application logics by assigning functionality
>>to different general purpose languages I have to admit that I don't
>>think it is such a great idea ...

>In my experience, Flex + Python gives you the best of both worlds,
>the nice GUI features of Flex and the efficiency of Python for the
>business logic.
>>
>A long time ago, there was a Python plugin for Netscape
>which allowed you to run Python straight in the browser. Perhaps
>it's time to revive such an idea... but then you're still missing
>out on the GUI part, since you're still stuck with what the
>browser has to offer in terms of widget support.
>>
>--
>Marc-Andre Lemburg
>eGenix.com
>>
>Professional Python Services directly from the Source (#1, Sep 04 2008)

>>>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>>>mxODBC.Zope .Database.Adapt er ... http://zope.egenix.com/
>>>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

>______________ _______________ _______________ _______________ _____________
>>
>:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::
>>
>>
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
>--
>http://mail.python.org/mailman/listinfo/python-list
>>

>
>
>
>
------------------------------------------------------------------------
>
--
http://mail.python.org/mailman/listinfo/python-list

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Sep 04 2008)

>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>mxODBC.Zope.D atabase.Adapter ... http://zope.egenix.com/
>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

_______________ _______________ _______________ _______________ ____________

:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611

[Peter Decker]

Re: PyGUI as a standard GUI API for Python?

On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch <deets@nospam.w eb.dewrote:

Michael Palmer schrieb:

>>
>As anyone knows, the state of Python GUI programming is a little
>fractured at this time, with many toolkits, wrappers and meta-wrappers
>dead and alive, with or without documentation.
>>
>I've come across two projects that have the appeal of striving for
>simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
>wxPython. It is lacking documentation but actually quite usable and
>concise. The other, PyGUI, has an even nicer API and more docs but has
>relatively few widgets implemented at this time. It also strives for
>compatibilit y with several toolkits (two at this time), which I think
>is the right idea.

>
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 .

With all due respect, it seems like you are not terribly familiar with
wxPython. It uses the native UI toolkit for each platform wherever
possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications
tend to look 'natural' on each platform, rather than uniform across
platforms, and I believe that this is what most people prefer.

--

# p.d.

[Diez B. Roggisch]

Re: PyGUI as a standard GUI API for Python?

Peter Decker schrieb:

On Wed, Sep 3, 2008 at 11:57 AM, Diez B. Roggisch <deets@nospam.w eb.dewrote:

>Michael Palmer schrieb:

>>As anyone knows, the state of Python GUI programming is a little
>>fractured at this time, with many toolkits, wrappers and meta-wrappers
>>dead and alive, with or without documentation.
>>>
>>I've come across two projects that have the appeal of striving for
>>simple, pythonic APIs: PyGUI and wax. The latter is a wrapper around
>>wxPython. It is lacking documentation but actually quite usable and
>>concise. The other, PyGUI, has an even nicer API and more docs but has
>>relatively few widgets implemented at this time. It also strives for
>>compatibili ty with several toolkits (two at this time), which I think
>>is the right idea.

>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 .

>
With all due respect, it seems like you are not terribly familiar with
wxPython. It uses the native UI toolkit for each platform wherever
possible: Aqua on OS X; MFC on Windows and Gtk on Linux. Applications
tend to look 'natural' on each platform, rather than uniform across
platforms, and I believe that this is what most people prefer.

You got me wrong. I didn't say it doesn't use the native toolkit under
various OSes, I'm well aware of that it does.

What I *did* say was that wx API is designed primarily with windows'
toolkit as base, and as a consequence the API tends to be less
functional for other toolkits, making it harder to work with it. As the
OP was after a "one API to rule them all" for GUIs, I pointed that out.

See for example this (arguably somewhat dated) post that illustrates my
point:

http://mail.python.org/pipermail/python-list/2005-March/313354.html

From my personal experience with Qt and Cocoa, I can say that both are
great, but their full power is unleashed only if used directly - talk
about Multi-threading in Qt4, or KeyValue-coding in Cocoa. Neither is
available in wx.

Diez

[Todd Whiteman]

Re: PyGUI as a standard GUI API for Python?

M.-A. Lemburg wrote:

A long time ago, there was a Python plugin for Netscape
which allowed you to run Python straight in the browser. Perhaps
it's time to revive such an idea... but then you're still missing
out on the GUI part, since you're still stuck with what the
browser has to offer in terms of widget support.
>

There is still a plugin (extension) for Mozilla based products, that
enables use of Python in products like Firefox:

http://pyxpcomext.mozdev.org/

Mark Hammond's Python/Mozilla work has enabled products like Komodo,
Miro (Democracy) and the OLPC project to use Python as a major driver
for consistent cross-platform GUI applications.

Personally, I believe XULRunner has a lot to offer for Python GUI
development, I'm currently finishing up some documentation steps to show
off how to use it specifically for Python (I'll post it to this list
when it's finished).

Cheers,
Todd

[Peter Decker]

Re: PyGUI as a standard GUI API for Python?

On Fri, Sep 5, 2008 at 10:48 AM, Diez B. Roggisch <deets@nospam.w eb.dewrote:

You got me wrong. I didn't say it doesn't use the native toolkit under
various OSes, I'm well aware of that it does.
>
What I *did* say was that wx API is designed primarily with windows' toolkit
as base, and as a consequence the API tends to be less functional for other
toolkits, making it harder to work with it. As the OP was after a "one API
to rule them all" for GUIs, I pointed that out.
>
See for example this (arguably somewhat dated) post that illustrates my
point:
>
http://mail.python.org/pipermail/pyt...ch/313354.html

OK, that's a little clearer.

That's one of the things that I like about Dabo - it gets rid of the
ugly (IMO) wxPython API and replaces it with a much more consistent
(and, IMO) more Pythonic API. I hated coding in wx, but I love coding
in Dabo.

--

# p.d.