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]

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]

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.

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]

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.


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)]

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]

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.

 

[Kay Schluehr]

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]

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)________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,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]

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+FlashPlayer.
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]

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

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)________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,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]

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.

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)
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,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

--
Marc-Andre Lemburg
eGenix.com

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

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,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]

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.

 

[Diez B. Roggisch]

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]

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]

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

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.

 

[Fred Pacquier]

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

That would be really nice !

I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...

TIA,
fp

 

[David Trem]

That would be really nice !

I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...

TIA,
fp

I will also like to see such documentation as soon as possible.
To me, XUL+python really looks like what could be my prefered solution
for multiplatform GUI for my python program.
I'm really impatient and hope a strong and motivated community could
set up arrond such XUL+python project.

All the best,

David

 

[David Trem]

That would be really nice !

I've long been curious about the potential of XUL+Python, but put off by
the lack of leads to follow up, and not having time to do the digging
myself...

TIA,
fp

I will also like to see such documentation as soon as possible.
To me, XUL+python really looks like what could be my prefered solution
for multiplatform GUI for my python program.
I'm really impatient and hope a strong and motivated community could
set up arrond such XUL+python project.

All the best,

David

 

[Todd Whiteman]

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

Here is the tutorial I've started in order to show off building a
Python/XULRunner GUI application.
http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xulrunner_about.html

The details in this tutorial mostly targets a Windows/Linux platform
(MacOSX is possible with a few deviations, I have tried to cover these
deviations where applicable).

Feedback is welcome.

Cheers,
Todd

 

[lkcl]

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.

http://pyjd.org
tadaaaaa
(based on webkit, just like adobe air is).