[Python-3000] Add a standard GUI system

[Josiah Carlson]

Bill Janssen <janssen at parc.com> wrote:
> 
> > Python already comes with a standard GUI toolkit; tk.
> 
> With a decidedly unpythonic bad interface.  And it's not standard; I
> frequently find Python installations where no one has installed Tk.
> Pardon me for being blunt:  Tkinter is a half-assed "solution" that's
> set Python back for years.

No argument here; I tried to use Tk, spent a weekend with it, got
frustrated, tried wxPython, and was going in about 30 minutes.

I've only ever really dealt with Windows GUI programming, so it was
certainly my mistake to assume that Tk was always available with Python.


> >  Also, while I
> > generally like Greg Ewing's work (Pyrex has saved me so much brain power
> > interfacing with C extensions), PyGUI doesn't have nearly the market
> > penetration (into the Python GUI toolkit area) to justify its inclusion
> > into the python standard library.
> 
> Doesn't matter.  Putting it into the stdlib will solve the penetration
> problem.

Yes and no.  It will only really solve the penetration problem it if it
actually superior to the other options available (in widget availability,
ease of use, etc.). Note how Tk in Python isn't used nearly as often as
wxPython is?


> > Also, it would require shipping a Python GTK binding, which would
> > basically necessitate shipping GTK+ with Python.
> 
> No, it wouldn't.  It runs natively on Mac OS X, and could be made to
> do on Windows.  I'd suggest using the existing GTK+ binding for Linux,
> and only in the interim for Windows.  I certainly wouldn't ship GTK+
> with Python, or wxWindows either.  As I suggested, I think that it
> would be a good idea to do a PyGUI port to a lower-level system, such
> as cairo, for more generic use.  I wouldn't object to shipping cairo
> to those few systems where it won't be pre-installed.

Ultimately, PyGUI is essentially a wrapper of native or near-native
widgets into a common interface.  wxPython is exactly the same thing,
only it has a much larger user base, developer support, and (native and
emulated) platform support.  Similar things can be said about the GTK
and Qt bindings for Python (at least in terms of user base, developer
and platform support), but I don't have experience with PyGTK or PyQt,
so cannot comment on their quality/support/etc. versus wxPython.

I should also mention that while it would take Greg and/or others a
time to go and wrap the Windows native widgets, it has already been done
with wxPython.


> > it's market penetration (into the Python GUI toolkit area)
> > is growing steadily
> 
> Pointless consideration.  Tkinter has a great penetration, but it's a
> bad solution.

It is not pointless.  Even though it is more difficult to install
wxPython than Tk (which should have build rules in the Python source,
and should be distributed with the Python binaries, if I understand
correctly), it is still used far more than the Python Tk bindings.  In
this case, wxPython's market penetration at least suggests
higher-quality.

 - Josiah