Future Python Gui?
kirkjobsluder at gmail.com
Wed Apr 18 22:47:57 CEST 2007
On Apr 18, 11:24 am, "bcwh... at pobox.com" <bcwh... at pobox.com> wrote:
> > I'd say that the best bet is to learn swig and similar
> > bridging, expanding, and embedding mechanisms.
> > Python GUI programming is likely to involve either
> > python hooking into frameworks like Cocoa, Qt, or
> > wxWidgets, python embedded in frameworks
> > like Java or .NET, or flavors of python used
> > as domain-specific languages in applications such as
> > emacs, vim, and OpenOffice.org.
> If this were just a tool for me, it wouldn't matter. My concern is
> distribution. If anybody who wants to run my software then they also
> have to go through all the trouble to install these extensions, none
> of which seem to have decent instructions. I'm an old-time hack and I
> have trouble getting them to work. A simple user won't have a chance!
Deployment has improved a lot in recent years, PyObjC is a simple
double-click on a package. Most windows libraries work the same way.
On the FOSS Unix world, you would add to a package system which will
install dependencies automatically. When I used a FOSS Unix, I really
only got burned when I decided to live on the bleeding edge. And as
someone else pointed out, package tools should take much of the work
out of delivery.
Meanwhile, things could work the other way around. If Apple extends
their support to PyObjC for example, python developers would know that
every new OS X system would be able to run their PyObjC.
> If Python doesn't declare an official Gui system, then it'll be
> fragmented, inconsistent, and unsupportable.
I don't see that as the case because many other languages don't have
an "official" GUI system including C, C++, Ruby, lisp, Basic and
perl. All of these have their active areas of deployment. For that
matter, Java has three "official" GUI systems with most development on
the server side.
And didn't comp.long.python have this same argument in regards to
MySQL support which was dropped from php? In addition to license
issues, the php core library just wasn't used, and lagged behind the
My personal opinion is that GUI development is such a moving target
that toolkits are a poor choice for inclusion into the core standard
libraries. There does not appear to be a standards process involved,
and toolkits are expanding or changing parts of their API every few
years. Anything that could be added, is going to be obsolete by the
time it is incorporated into the standard. My feeling is that python
is better served by encouraging GUI developers to include python-
> I wouldn't mind using just Tkinter, despite it's primative look,
> except that it doesn't support more advanced widgets like "notebook".
I wouldn't mind seeing tkgrid and tkhtml added to the standard
library. But Tk is probably "good enough" for most simple
> -- Brian
More information about the Python-list