On Jul 20, 3:34 am, Terry Reedy <tjre...@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. -- http://mail.python.org/mailman/listinfo/python-list
