Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
In message [EMAIL PROTECTED], Grant Edwards wrote: You've got to admit that Tk just works, although as a result it looks ugly and foreign on all platforms. Sort of a pidgin GUI. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 10/2/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? No, but it's larger than wx on top of the native API, so when you average it across all platforms it's quite a bit larger. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 10/2/07, bramble [EMAIL PROTECTED] wrote: On Oct 2, 11:07 am, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) as well as a complicated runtime environment. What's complicated about it? There's an enormous amount of dependencies and runtime configuration, such as finding theme engines and handling preferences. There's solutions for managing all of that of course, but it's still much more overhead than dirt-simple Tk. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 2007-10-03, Chris Mellon [EMAIL PROTECTED] wrote: On 10/2/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? No, but it's larger than wx on top of the native API, A moot point for X11. so when you average it across all platforms it's quite a bit larger. I guess that's one of the costs of portability. -- Grant Edwards grante Yow! CHUBBY CHECKER just at had a CHICKEN SANDWICH in visi.comdowntown DULUTH! -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 2007-10-03, Chris Mellon [EMAIL PROTECTED] wrote: On 10/2/07, bramble [EMAIL PROTECTED] wrote: On Oct 2, 11:07 am, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) as well as a complicated runtime environment. What's complicated about it? There's an enormous amount of dependencies and runtime configuration, such as finding theme engines and handling preferences. There's solutions for managing all of that of course, but it's still much more overhead than dirt-simple Tk. You've got to admit that Tk just works, although as a result it looks ugly and foreign on all platforms. -- Grant Edwards grante Yow! So this is what it at feels like to be potato visi.comsalad -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 10/3/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-03, Chris Mellon [EMAIL PROTECTED] wrote: On 10/2/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? No, but it's larger than wx on top of the native API, A moot point for X11. wxWidgets actually does have a raw X11 implementation, although nobody uses it so it's not well maintained. And since X11 is hardly the only platform that anyone cares about, evaluating a potential addition to the standard library across *all* platforms is important. so when you average it across all platforms it's quite a bit larger. I guess that's one of the costs of portability. Eh? The point is that wxWidgets, the more portable toolkit, is *smaller* than Gtk. It's not really related to portability as much as design considerations. Gtk is designed and intended to be used as a system library, in conjunction with many other system libraries and lots of system-level configuration. It was never written with the goal of being an application-level toolkit. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 3, 1:39 pm, Chris Mellon [EMAIL PROTECTED] wrote: On 10/3/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-03, Chris Mellon [EMAIL PROTECTED] wrote: On 10/2/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? No, but it's larger than wx on top of the native API, A moot point for X11. wxWidgets actually does have a raw X11 implementation, Wait though. If I want to use wxPython, my python code calls wxWidgets code which calls gtk. So, it would seem simpler to remove 1 layer and just call the gtk code directly via PyGTK. so when you average it across all platforms it's quite a bit larger. I guess that's one of the costs of portability. Eh? The point is that wxWidgets, the more portable toolkit, is *smaller* than Gtk. It's not really related to portability as much as design considerations. Isn't wxWidgets smaller that GTK+ simply because it's a wrapper and doesn't do its own drawing? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 10/3/07, bramble [EMAIL PROTECTED] wrote: On Oct 3, 1:39 pm, Chris Mellon [EMAIL PROTECTED] wrote: On 10/3/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-03, Chris Mellon [EMAIL PROTECTED] wrote: On 10/2/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? No, but it's larger than wx on top of the native API, A moot point for X11. wxWidgets actually does have a raw X11 implementation, Wait though. If I want to use wxPython, my python code calls wxWidgets code which calls gtk. So, it would seem simpler to remove 1 layer and just call the gtk code directly via PyGTK. By the same argument, you could say that Gtk just calls xlib, so why not write against xlib directly? More direct is not always simpler. But the real reason, of course, is that wxWidgets is a platform abstraction API, and Gtk isn't. Anyway, this discussion isn't about the relative merits of wxWidgets and PyGtk in general, but specifically for inclusion in the standard library. so when you average it across all platforms it's quite a bit larger. I guess that's one of the costs of portability. Eh? The point is that wxWidgets, the more portable toolkit, is *smaller* than Gtk. It's not really related to portability as much as design considerations. Isn't wxWidgets smaller that GTK+ simply because it's a wrapper and doesn't do its own drawing? Not really, no. Qt also does all of its own drawing and is a fraction of the size of Gtk. The amount of code thats responsible for drawing is minuscule. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
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? There is no secret weapon. It's a question about dependencies, maintenance, stability and supported platforms. Using one of the other Toolkits would mean that an awful lot of libraries need to be included as well - even nowadays, people complain about the size of a python distribution. Then something in the core libraries has to be actively reliably maintained to not endanger the overall release cycles. Linked to that is the question of stability - not so much as it doesn't crash but more on the lines of it doesn't move so fast people cry for newer versions all the time And last but not least is Tk available on a wide range of platforms, larger than more or less every other toolkit. I know of a popular source control software which vendor chose Tk for the same reason. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 2 Okt, 04:54, bramble [EMAIL PROTECTED] wrote: Maybe the key I'm missing is this: maybe GvR and company think that a language absolutely should come off-the-shelf with GUI toolkit bindings. So, given that, they feel they've gotta pick just one, and they've already got Tkinter and it works, so that's that. Is that it? Yes. Also, Tk isn't a particularly fast-moving target compared to some of the other toolkits, so it's possible to not spend too much time maintaining the bindings for it, I imagine. Otherwise, Tkinter might have fallen out of the standard library by now. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Tue, 2007-10-02 at 03:04 +, bramble wrote: But Py3k is all about breaking compatibility That's a complete distortion of Python 3.0's mission. Python 3.0 breaks backwards compatibility only where there exist good reasons to do so. As Guido put it in a recent Python-3000 post, Python 3000 is boldly choosing to be backwards compatible, except in cases where a real benefit can be obtained by being incompatible. So, unless you can make a case that a real benefit can be obtained by removing Tkinter, it'll stay. -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble wrote: 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? Wouldn't license compatability be an issue? Tk's license is BSD-style, which means it plays nice with both proprietary and open-source software (as does Python's license). Aren't PyGtk and wxPython LGPL? And PyQt is either GPL or proprietary. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | I don't know... As I meant to imply above, it's looking like Tkinter | will be playing its expected role in Py3k as the GUI toolkit of | choice. And from what I've seen of the Py3k effort, there's been | really excellent work on pulling out stuff that should be pulled out. | So, if it was *really* simply only first-mover advantage keeping it | there, I'd expect to see talk of removing it from the standard | library. First, the 3.0a1 release put off modification of the stdlib. Second, Guido wants to distribute a minimal development environment - Idle - and that is written in TKinter. Third, I have not seen a formal proposal from the authors of any other GUI toolkit that such replace TKinter or even supplement it. There are disadvantages as well as advantages to having one's work in the stdlib. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Monday 01 October 2007 21:04, bramble 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? Tkinter's secret weapon are pgmrs like me that would rather put pressure on the Tk people to improve what already is working. Update and improve Tk, change the look and feel of it, add features. Let me spend my time programming not trying to make existing programs compatible with the unknown. (Some change to who knows what.) On the other hand, questions like yours are exactly what keeps the pressure on the Tkinter people to upgrade. I think they got the message with the recent announcement of some long awaited changes. jim-on-linux http://inqvista.com -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
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
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 5:29 am, Paul Boddie [EMAIL PROTECTED] wrote: On 2 Okt, 04:54, bramble [EMAIL PROTECTED] wrote: Maybe the key I'm missing is this: maybe GvR and company think that a language absolutely should come off-the-shelf with GUI toolkit bindings. So, given that, they feel they've gotta pick just one, and they've already got Tkinter and it works, so that's that. Is that it? Yes. Ahh... Ok. Thanks, that explains it. At first, it hadn't ocurred to me that anyone would want to provide a GUI toolkit binding along with a popular general purpose programming language implementation. Moreover, it *really* wouldn't occur to me that they'd also want to provide an IDE (as Terry mentions in another reply). But then, I'm looking at Python today, in 2007, at a time when Python has multiple high-quality GUI toolkit bindings available, and when most editors and IDE's have excellent Python support built-in. Given that line of reasoning though, it seems odd to me that GvR and Co. would still regard shipping those as part of Python proper as a requirement for Py3k. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 7:33 am, Carsten Haese [EMAIL PROTECTED] wrote: On Tue, 2007-10-02 at 03:04 +, bramble wrote: But Py3k is all about breaking compatibility That's a complete distortion of Python 3.0's mission. Python 3.0 breaks backwards compatibility only where there exist good reasons to do so. As Guido put it in a recent Python-3000 post, Python 3000 is boldly choosing to be backwards compatible, except in cases where a real benefit can be obtained by being incompatible. So, unless you can make a case that a real benefit can be obtained by removing Tkinter, it'll stay. Well, it of course wouldn't break backward compatibility by simply removing it from the standard library and providing it as an optional extra set of modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble wrote: 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? On the OS vendor level, it may not be beating Tkinter. OSX 10.4 comes out of the box (no action by the user required to install it) with python 2.3.5 + wx 2.5.3.1: mbi136-54 25% /usr/bin/python Python 2.3.5 (#1, Aug 19 2006, 21:31:42) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type help, copyright, credits or license for more information. py import wx py wx.__version__ '2.5.3.1' py ^D mbi136-54 27% uname -v Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 Consider also that a similar setup with ubuntu is only an apt-get away. And, if you know the proper incantations, is probably just as easy with fedora. Window$ of course...cousucksgh...Excuse me...doesn't get support for anything like that from micr$oft, but I think its very easy with enthought. So in some ways, Tkinter appears to be simply vestigial. James -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 2 Okt, 22:35, bramble [EMAIL PROTECTED] wrote: Ahh... Ok. Thanks, that explains it. At first, it hadn't ocurred to me that anyone would want to provide a GUI toolkit binding along with a popular general purpose programming language implementation. Moreover, it *really* wouldn't occur to me that they'd also want to provide an IDE (as Terry mentions in another reply). But then, I'm looking at Python today, in 2007, at a time when Python has multiple high-quality GUI toolkit bindings available, and when most editors and IDE's have excellent Python support built-in. Yes, and if you consider the situation about ten or more years ago, it was rather different from now: Tk had been the most promising open source cross-platform toolkit for a number of years (Qt wasn't open source until 1998 and wasn't Free Software until 2000 [1]; Gtk+ was only just getting started [2]; wxWindows, as it was then - and should really still be - provided support for different backends, but on UNIX- like platforms relied on legacy toolkits like Xt and Motif [3]), and many languages offered Tk bindings in order to show their suitability for GUI programming. Java was probably the first notable mainstream language of the day to shun Tk, but even languages/runtimes like Limbo/ Inferno (which wasn't open source back then) provided a Tk-like interface if not Tk itself, and I think a number of less well-known languages of a certain age offer Tk bindings just as the standard CPython distribution does. Given that line of reasoning though, it seems odd to me that GvR and Co. would still regard shipping those as part of Python proper as a requirement for Py3k. If they aren't broken then there's no need to fix them, even after the controlled breakage involved in the making of Python 3000. ;-) Paul [1] http://trolltech.com/company/about/milestones (note the difference between open source and the stricter Free Software criteria) [2] http://docs.gimp.org/en/gimp-introduction-history-early-days.html [3] http://www.wxwidgets.org/about/history.htm -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 2, 11:07 am, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) as well as a complicated runtime environment. What's complicated about it? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On 2007-10-02, Chris Mellon [EMAIL PROTECTED] wrote: PyGtk has poor cross platform support, a very large footprint (the largest of all these libraries) It's larger than wxWidgets on top of Gtk? 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. I like the fact that it doesn't include a whole extra scripting language interpreter along with it the way tkinter sucks in Tcl. -- Grant Edwards grante Yow! I'm encased in the at lining of a pure pork visi.comsausage!! -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
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? The trick is very simple. Tkinter just *doesn't* get much focus. Very few of the core developers actively work on it; I do so only once every two years or so to merge all the patches that get contributed. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
gui toolkits: the real story? (Tkinter, PyGTK, etc.)
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble [EMAIL PROTECTED] writes: 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? First-mover advantage. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 8:04 pm, 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 was there at the beginning unlike bindings to wxWidgets or QT so it got all the standard library modules, too and they are still supported not to break compatability. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 9:14 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: bramble [EMAIL PROTECTED] writes: 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? First-mover advantage. I don't know... As I meant to imply above, it's looking like Tkinter will be playing its expected role in Py3k as the GUI toolkit of choice. And from what I've seen of the Py3k effort, there's been really excellent work on pulling out stuff that should be pulled out. So, if it was *really* simply only first-mover advantage keeping it there, I'd expect to see talk of removing it from the standard library. BTW, pulling Tkinter and related GUI stuff out of Py3k's standard library wouldn't harm existing Tkinter users -- it would merely require them to actually install it if they want it. Maybe the key I'm missing is this: maybe GvR and company think that a language absolutely should come off-the-shelf with GUI toolkit bindings. So, given that, they feel they've gotta pick just one, and they've already got Tkinter and it works, so that's that. Is that it? -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 10:54 pm, bramble [EMAIL PROTECTED] wrote: BTW, pulling Tkinter and related GUI stuff out of Py3k's standard library wouldn't harm existing Tkinter users -- it would merely require them to actually install it if they want it. Oops. I meant to put in there, after the BTW,: it seems to me that. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
On Oct 1, 10:34 pm, Benjamin [EMAIL PROTECTED] wrote: and they are still supported not to break compatability. Hm. Ok. I can see that for the 2.x releases. But Py3k is all about breaking compatibility, so, it would seem there's more to the story. -- http://mail.python.org/mailman/listinfo/python-list
Re: gui toolkits: the real story? (Tkinter, PyGTK, etc.)
bramble wrote: On Oct 1, 10:34 pm, Benjamin [EMAIL PROTECTED] wrote: and they are still supported not to break compatability. Hm. Ok. I can see that for the 2.x releases. But Py3k is all about breaking compatibility, so, it would seem there's more to the story. Yes, compatibility is broken, strictly speaking; however, the goal is that the majority of changes can be handled automatically using the 2to3 tool to convert the source code. You can't really do that if you remove Tkinter entirely. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
