On Jul 19, 9:44 pm, Kevin Walzer <k...@codebykevin.com> wrote: > > 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.
Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a TCL interpreter. You statements are misleading. > > 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. He did not even mention Tk in that block, do you have a TK persecution complex? > > 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. This is true. Lots of people lack the skill to create professional quality GUI applications however lots of GUI devs lack the skill to create clean and intuitive API's also. Tkinter/TclTk and WxPython \WxWidgets has lots of warts in this respect. > > 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? Just because someone wants to entertain ideas for a new GUI does mean they are starting flame wars. I would say out all the responses so far YOURS is the most emotional. > > 1. Lean and mean -- do nothing but GUI. No database API, networking > > API, threading API, etc. > > Presenting...Tk. True Tkinter does no Database, networking, threading, etc. However i would not call an embedded TCl interpreter "lean and mean". > > 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. I will agree with Kevin here. Hey, he's not ALWAYS wrong you know; just most of the time! ;-) > > 6. Expose the event loop to Python. > > Presenting...Tk. Tk's event binding (whist quite powerful) is also quite overwhelming in the sheer number of event sequences alone and leads to spaghetti code. See my recent thread about the subject. > > 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. I think it could happen much sooner if people got serious. However it won't happen tomorrow for sure. > > Is it worth the hassle to start a new GUI toolkit project? > > Not unless you want to reinvent the wheel yet again. The old "reinvent the wheel" argument is only valid when wheels already exists. Currently we have triangles (or maybe pentagons) but no wheels. -- http://mail.python.org/mailman/listinfo/python-list
