On Wednesday 03 March 2004 02:45 pm, Andy Sy wrote: > Michael McLay wrote: > > 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 agree. They have a minimal GDK layer and a minimal Gtk layer. That puts very little between Python and the bare metal. > > 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 suggesting this be done quickly. I know it is code bloat to have two GUI toolkits in the library, but only one would be used per process, so there would be minimal memory consumption at run time. Also, for many situations, the GTk libraries would already be loaded in as libraries, so the overhead of the Python importing of the library would probably be minimal. Tkinter is the odd man out in this situation. It isn't used for the Gnome window manager, the Mozilla browser, or any other major application. > > 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! :-) Hopefully it would be a thin layer. Replacing the native TCL version might also prompt people to rewrite their Tkinter apps directly in PyGtk. Most likely this will never happen. Who would find the project in their self interest? > > 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. The Tkinter 3000 coma is all the more reason why we need to move to a GUI that is growing in popularity. I just saw another critique of Python in which the lack of a good GUI and IDE are referenced as the reason Python isn't growing a larger market share. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
