On 7/20/11 9:05 AM, rantingrick wrote:
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.
Of course I know this--I'm one of the core Tcl/Tk developers on my
platform. :-) My statement was actually based on Mark Lutz's
characterization in "Programming Python," when he defends Tk's inclusion
in the stdlib (and his own book's extensive focus on it) by observing
that the toolkit was specifically designed for use with scripting
languages--Tcl at the start, but also Python, Perl, Ruby...he seemed to
want to downplay Tk's Tcl-ish roots, as if he were embarassed by them. I
guess it's a Tcl-ish subject.
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?
No, but it's an advantage that Tk has over the other ones, and an
argument that reinventing the wheel is unncessary.
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.
I think what constitutes a "clean API" is partly a matter of taste.
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.
*shrug*
Maybe it is. I prefaced this by saying, "OK, I'll bite," which suggests
that perhaps I shouldn't, because complaints and hand-wringing are
really a waste of time. In the future, I think my response (if I make
one at all) will more likely be something like this:
"An interesting idea. Please post back when you have a source code repo,
build instructions so we can play with your code, a mailing list, and a
license that is suitable for both open-source and proprietary development."
The most substantial effort at developing a new GUI API for Python did
just this--PySide (alternative bindings to Qt). No hand-wringing, no
flame wars, just an announcement of the project, an invitation to
contribute, and so on. Whether you think it's a misguided project or an
attempt to reinvent the wheel is beside the point--it's a substantial
project, with both leadership and a growing community that support
ongoing development and rapid maturation.
In my own experience, this is the only way to move things forward or
bring about any useful change--roll up my sleeves and do it myself. I've
done this a bit with Tkinter (maintaining bindings/wrappers to a popular
Tk widget, tablelist), but I've done this extensively with Tk itself on
the Mac. I complained on mailing lists for years that Tk didn't do this
or that on the Mac, and these complaints fell on deaf ears; finally, I
decided to dive into the deep end, learn the low-level API's to do what
I wanted, and bingo! Suddenly Tk did what I wanted.
That's the essence of open-source development--scratching your own itch.
Sometimes you get lucky and a large corporate entity has an itch to
scratch, and this can bring large-scale projects with large-scale
benefits. I believe Nokia is funding PySide. While Tk's port to the
Mac's Cocoa API was done by a single developer, the project was funded
by Apple. Creating a new GUI toolkit may require this scale of effort
and investment. But even without it, if a developer can get something
started and make enough progress to be of interest to others, then a
larger community may move the project forward.
Code trumps everything.
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".
Perhaps not. Creating a pure-Python GUI toolkit that provides native
integration with X11, Windows, and OS X windowing systems would be "lean
and mean"--but it would also be a lot of work. And, assuming the project
went forth to completion, I bet that other scripting languages would
piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit,
anyone?) because doing that is less work than writing your own toolkit
from scratch.
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! ;-)
Meh.
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.
This is a matter of taste.
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.
Certainly not.
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.
Well, I have two closing responses:
"Let's see your code, repo, mailing list, and license."
and:
"I'm bowing out now."
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list
