I am fed up with Python GUI toolkits...

[lkcl]

On Jul 20, 3:34 am, Terry Reedy <tjre... at udel.edu> wrote:
> On 7/19/2011 10:12 PM, sturlamolden wrote:
>
>
>
> > What is wrong with them:
>
> > 1. Designed for other languages, particularly C++, tcl and Java.
>
> > 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
> > has a standard library!)
>
> > 3. Unpythonic memory management: Python references to deleted C++
> > objects (PyQt). Manual dialog destruction (wxPython). Parent-child
> > ownership might be smart in C++, but in Python we have a garbage
> > collector.
>
> > 4. They might look bad (Tkinter, Swing with Jython).
>
> > 5. All projects to write a Python GUI toolkit die before they are
> > finished. (General lack of interest, bindings for Qt or wxWidgets
> > bloatware are mature, momentum for web development etc.)
>
> Greg Ewing's pygui project is still going and releasing new versions.
>
>
>
> > How I would prefer the GUI library to be, if based on "native"
> > widgets:
>
> > 1. Lean and mean -- do nothing but GUI. No database API, networking
> > API, threading API, etc.
>
> > 2. Do as much processing in Python as possible. No more native code
> > (C, C++, Cython) than needed.
>
> > 3. Instances of extension types can clean themselves up on
> > deallocation. No parent-child ownership model to mess things up. No
> > manual clean-up. Python does all the reference counting we need.
>
> > 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is
> > suitable.
>
> > 5. No particular GUI thread synchronization is needed  -- Python has a
> > GIL.
>
> > 6. Expose the event loop to Python.
>
> > 7. Preferably BSD-style license, not even LGPL.
>
> > 8. Written for Python in Python -- not bindings for a C++ or tcl
> > toolkit.
>
> I think you described pygui.
>
> > Is it worth the hassle to start a new GUI toolkit project?
>
> Ask Greg what you might help with.
>
> > Or should modern deskop apps be written with something completely
> > different, such as HTML5?
>
> An interesting question. I think thepyjamasproject is aimed in this
> direction,

 weeelll... we kinda want to keep as many platforms supported as
possible, so that includes IE6 canvas (VML) which surprisingly works
pretty damn good, the only thing missing is being able to add text to
VML canvas: everything else (including colour gradients) shockingly
actually works.  it's slow, but what do you expect out of IE6, duh.

 but yes we're finding that an increasing number of people are saying
"i wrote a pyajamas app, it used direct HTML5, sod the browsers that
don't properly support HTML5" and i think that's a good thing.


> but the author says he will never port to Py3. (He explained
> his reasons on this list when I suggested that.)

 :)  it's not quiiite a matter of "never" - it's conditional.  the
conditions on which i, personally and extremely grudgingly, will get
involved in a py3 port of pyjamas are when it becomes hellishly
difficult for myself, personally, to maintain all of the components of
pyjamas *including* the desktop ports (w32 MSHTML, gnu pythonwebkit
project, xulrunner N.N) which people tend to forget exist for python
2.N.  the reason for that are a) personally i don't like py3 (because
it didn't include backwards-compatibility for python 2) b) the pyjs
translator is self-contained, and has at absolutely no time any need
for any links at runtime to in fact any python *at all* (because the
pyjs version runs on a javascript engine *not* a python engine).

 there's no "never" in there - it's just that i'll keep reviewing the
situation, and i anticipate / predict that it will begin to become
difficult to compile python2 applications (such as python-comtypes) at
some point in approx ooo... 5 to 7 years.  maybe not - it's hard to
say.

 anyway - if however someone else wants to collaborate and/or fund a
py3 port of pyjamas, knock yourself out: just bear in mind that it's
an estimated 18 man-month project.

 l.