On Tuesday 02 March 2004 11:24 pm, Andy Sy wrote:
AS> Michael McLay wrote almost a year ago:
MM>The Tkinter library in the standard Linux distribution is getting long in MM>the tooth. It is in the standard distribution because it provides MM>cross-platform portability and has a rich text widget. The rate of MM>improvement in the Tk toolkit has slowed to a trickle and the marketshare MM>of Tk continues to shrink. Is it time to look for a replacement that MM>would be a comfortable fit within the standard Python library? MM> MM><snip>
AS> Due to its maturity under Win32 and superbly friendly learning curve, I am AS> also convinced that PyGtk is the way to go (over Tkinter, wxPython, and AS> PyQt).
I'm glad to hear you agree with my thoughts on the subject. It won't be easy to convince the skeptical gatekeepers who control the standard library. The case for selecting PyGtk instead of wxPython will be particularly tough, given the large user base that GUI toolkit has attracted. This will require showing that PyGtk does everything wxPython can do and that PyGtk is a better fit in general. Your thoughts on how to do this would be appreciated.
I've only had a cursory introduction to wxPython and admittedly it, together with Qt, is more mature in both cross-platform support and functionality than Gtk. However, I consider PyGtk's API be far more elegant. I find Gtk code cleaner and easier to understand and as someone who's tried to learn PyQt, PyGtk, Tkinter and wxPython, I got the furthest with PyGtk (Tkinter is my second choice). This fact should help encourage more newbies to try out GUI programming under Python.
Furthermore, I feel that Gtk has the most easily understood and well-factored codebase. Gtk sits on top of GDK, a small platform-dependent core. Theoretically it is the only thing that needs to be reimplemented on a new platform to get Gtk running on it. In fact, they have already have Gtk running on DirectFB, meaning Gtk apps will not need X to run under Linux.
I've lost track of a very good email that described the characteristics of the PyGtk GUI library and why it looks like a natural component for the Python core library. I'd love to have that reference available. That email gave specific example of how Gtk fits with Python. From what I recall it contained some of the following observations: Gtk is a widely used, high quality GUI widget set. The implementation has been ported to a wide set of platforms. Gtk has a rich set of widgets. Gtk uses C as the implementation language. While Guido will not let GPL code into the Python core distribution, the LGPL is probably acceptable in the Python core library. While Tk, wxWindows, and Qt all have strengths, none of them are as good a fit to the Python core library as Gtk. At a technical level, the naming techniques used in Gtk seem to be very complementary to the hash table basis of the Python language. James' wrapping of Gtk 2.0 is a first class example of how to merge a large external library into a Python package. And finally, the combining PyGtk with the libglade module makes it very easy to get started building GUI based applications with Python. Eric Raymond's concern over the lack of good documentation for PyGtk is being addressed, but it would be much better if a good book on GUI programming with PyGtk and Python were available.
AS> I just remembered something though. How are you going to unbundle AS> Tkinter from the Python distribution without also dropping IDLE (which AS> I'm sure most of us would not want to do without)?
I'm not proposing dropping Tkinter. I'm suggesting that PyGtk be added as a second, and preferred, GUI for the standard Python distribution. There are other examples of duplicated capabilities in the standard Python distribution. Replacing older, less capable technology is a slow process. It took years for the re module to replace the original regular expression module in the library. The first step is to get the replacement added to the standard distribution.
My opinion on this matter is that it's got to be Tkinter OR PyGtk (can't be both) to avoid bloat. Further, any replacement has got to be in a comparable state of support and maturity as Tkinter. Unfortunately, I just checked it out and it turns out that Gtk2 support is at a very early stage for the Mac, so I guess PyGtk may not be ready to replace Tkinter as the standard Python GUI widget set just quite yet.
AS> Perhaps it would be a good exercise to port IDLE over to PyGtk? Since IDLE AS> does not seem to be widget-heavy, it may prove to be a fairly simple task.
Yes, I think IDLE would be a good candidate for a rewrite using PyGtk. It would be a good demonstration/test case.
More ambitious would be to layer Tkinter over the PyGtk module.
Ack, not another layer! :-)
> I think the PyGtk text widget was actually modeled after the Tk text widget. > It may not be practical. I recall early versions of Tkinter playing some tricks > that assume TCL is present. I don't know if this is still the case.
Tkinter, afaik, actually calls Tcl code which in turn calls Tk. This is why the Tcl DLLs (which I believe contains the interpreter) come with the Python distribution. This is also why it's so slow.
Tkinter 3000 was/is a project to completely replace this underlying mechanism, and I was quite keen on it a while back, but lately I haven't heard much about progress on it. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
