473,554 Members | 2,911 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

PyGUI as a standard GUI API for Python?

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

Sep 3 '08 #1
37 9022
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
Sep 3 '08 #2
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.


Sep 3 '08 #3
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
Sep 3 '08 #4
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
Sep 3 '08 #5
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
Sep 4 '08 #6
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
Sep 4 '08 #7
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.

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
Sep 4 '08 #8
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. 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 ...
Sep 4 '08 #9
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
Sep 4 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

108
7912
by: Zooko O'Whielacronx | last post by:
I'm a fan of Greg Ewing's PyGUI . I used it to code a simple game for my son , and enjoyed it. Programming with wxPython feels like programming with a C++ tool that has been wrapped in Python. Programming with PyGUI feels like programming with a real Python tool. If you're developing a commercial application in Python, wxPython is...
44
2491
by: Iwan van der Kleyn | last post by:
Please ignore if you are allergic to ramblings :-) Despite a puritan streak I've always tried to refrain from language wars or syntax bickering; call it enforced pragmatism. That's the main reason why I've liked Python: it's elegant and simple and still dynamic and flexible. You could do worse for a clean and pragmatic language. I do know...
0
798
by: DurumDara | last post by:
Hi ! Have the python standard mod. lib. a html/xml encoder functions/procedures ? like this: def ToSafeHTM(Text): s=ToHuStrSafe(Text) l= for c in s:
23
2371
by: gord | last post by:
As a complete novice in the study of Python, I am asking myself where this language is superior or better suited than others. For example, all I see in the tutorials are lots of examples of list processing, arithmetic calculations - all in a DOS-like environment. What is particularly disappointing is the absence of a Windows IDE, components...
3
3505
by: akbar | last post by:
I googled and searched in archive. All I can find is finding resolution with Tkinter and pygame. Any idea to find monitor resolution with standard python module? I can check from output of: xprop -root _NET_DESKTOP_GEOMETRY(CARDINAL) . The problem is when you use Beryl or Xgl, it is not correct anymore because Beryl or Xgl set this value...
2
4261
by: Kevin D. Smith | last post by:
I would like to move files and directories to the Recycle Bin on Windows from Python. I have found some older articles describing how to do this, but they require additional packages to be installed. I'm working on a plugin for an existing project and only have the standard library to work with. Is there a way to use the Recycle Bin using...
1
3825
by: dananrg | last post by:
Is there a module available in the standard library, for Python 2.4 running on Windows, like "crypt" for Python 2.4 running on *nix machines? I need to store database passwords in a Python 2.4 script, but obviously don't want them in clear text. I'm looking for a reasonable level of security. What are some of my options?
0
7581
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
1
7541
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7872
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6123
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5423
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3545
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3533
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2006
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
823
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.