Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx02.iad01.newshosting.com!novia!nx01.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!FUSE.NET-a2kHrUvQQWlmc!not-for-mail Message-ID: <4E26411A.4010203@codebykevin.com> Date: Tue, 19 Jul 2011 22:44:42 -0400 From: Kevin Walzer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Newsgroups: comp.lang.python Subject: Re: I am fed up with Python GUI toolkits... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@usenetserver.com Organization: UseNetServer.com Lines: 113 X-Trace: bbf444e26410ce7d07caf23999 Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:9930 OK, I'll bite... On 7/19/11 10:12 PM, sturlamolden wrote: > > 1. Designed for other languages, particularly C++, tcl and Java. So? Doing a GUI toolkit is a hard project. > > 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python > has a standard library!) Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit specifically designed for scripting languages. > > 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. Again, so? Again, this isn't applicable to Tk. > > 4. They might look bad (Tkinter, Swing with Jython). Then again, they might not. A lot depends on the skill of the developer. I write highly polished commercial apps with Tk GUI's. I'm sick of developers blaming their ugly apps on the toolkit rather than their own lack of design training and/or skills. > > 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.) That's right. People issue a clarion call for a new GUI toolkit, then discover that even a so-called "ugly, limited, minimalist" toolkit like Tk has twenty years of development behind it. And people think they can duplicate this effort in a few months by starting a flame war on comp.lang.python? > > 1. Lean and mean -- do nothing but GUI. No database API, networking > API, threading API, etc. Presenting...Tk. > > 2. Do as much processing in Python as possible. No more native code > (C, C++, Cython) than needed. And what's wrong with native (ie. compiled) code? Python is written in native code, isn't it? To extend Python in significant ways, it is often necessary to drop down into native code. > > 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. Presenting...Tk. > > 4. No artist framework. Use OpenGL, Cairo, AGG or whatever else is > suitable. "Artist framework"? I'm not sure what you mean here. > > 5. No particular GUI thread synchronization is needed -- Python has a > GIL. No comment here. > > 6. Expose the event loop to Python. Presenting...Tk. > > 7. Preferably BSD-style license, not even LGPL. Presenting...Tk. > > 8. Written for Python in Python -- not bindings for a C++ or tcl > toolkit. Well, that's the holy grail, but given the history of other toolkits, you'll reach a comparable level of maturity in 2031. > > > The Eclipse SWT library does some of this for Java does some of this, > though it also has flaws (e.g. manual memory management). A Python GUI > toolkit could be partially based on the SWT code. Your practical suggestion for the basis for a new Python GUI toolkit is...a Java GUI toolkit? I'm quite confused. > > Is it worth the hassle to start a new GUI toolkit project? Not unless you want to reinvent the wheel yet again. > > Or should modern deskop apps be written with something completely > different, such as HTML5? If it's written in HTML5, it is, by definition, not a desktop app. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com