On 10/1/07, bramble <[EMAIL PROTECTED]> wrote: > What is the backstory to why Python includes Tk bindings, as opposed > to some other set of bindings? > > I've written a few little Tkinter-based apps, and it's nice and > simple. I like it well enough. That said though, I keep feeling the > gravitational pull toward GTK+. I've been meaning to get the whole > glade+gtk+python thing happening with my own projects, as soon as time > allows. Is there resistance in the upper Python echelons to GTK > because of its LGPL licensing? > > Reading Alex's Nutshell book, right off the bat he comments that "The > most popular Python GUI toolkit today is probably wxPython". But then > he goes on for 45 pages on Tkinter... Seems like he wanted to write > that chapter on wx instead... > > WxWidgets, the last time I looked at it, seemed awfully like MS > Window's MFC. The licensing seemed vague at the time, and it looks > like wx contains an extra layer of GUI library, so I didn't spend any > real time on it. But, regardless, it seems to get good press among > python folk (I think I remember ESR noting how it was his GUI toolkit > of choice). > > PyQt has had that issue (IIRC) about needing to pay for it for > commercial apps, so I can see how there might be resistance to it > being considered the "standard Python GUI toolkit". > > So, it would seem to me that Tkinter *might* remain in Python proper, > but that I probably wouldn't see much effort put into it. Well, the > Python standard library docs tell a different story. There's stuff in > there about Tix, ScrolledText, turtle, and then the "other GUI > packages" doc page goes on about Python megawidgets (Tk-based) and > Tkinter3000 Widget Construction Kit (WCK). Wow. Looks like Tkinter is > still having serious support -- even though in that same doc at the > bottom notes, "PyGTK, PyQt, and wxPython, all have a modern look and > feel and far more widgets and better documentation than Tkinter." > > So, that leaves me wondering, why is Tkinter still getting so much > focus in the Python standard library? > > Maybe a better question is, how has Tk managed to keep beating up the > newer, more modern, more featureful, better documented toolkits > encroaching on his territory? What's Tk's secret weapon? >
Tk is stable, slow moving, highly portable, and liberally licensed. It's not very good except for that, but those are very important characteristics for something in the standard library. You'll note that Tix and the various other Tk "expansion packs" aren't in the stdlib. wxPython is LGPL with a binary linking exception - there's no license ambiguity there - but it develops far too fast to be in the stdlib. PyQt is GPL or commercial only and I wouldn't consider that suitable for a standard library package. PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) as well as a complicated runtime environment. It's probably the closest to suitable for standard library inclusion, but it doesn't have the binary linking exemption that wxPython does (theres some question as to how needed that is for Python code, though) and it's got no compelling API advantage over Tk. If you want to trade the large footprint for the more advanced toolkit, thats an option you have but I don't think it's a suitable standard library decision. -- http://mail.python.org/mailman/listinfo/python-list
