The Tkinter library in the standard Linux distribution is getting long in the tooth. It is in the standard distribution because it provides cross-platform portability and has a rich text widget. The rate of improvement in the Tk toolkit has slowed to a trickle and the marketshare of Tk continues to shrink. Is it time to look for a replacement that would be a comfortable fit within the standard Python library?
There are three major contenders in the cross-platform GUI race, PyGtk, wxPython and PyQT. Each of these options have strong Python support and a mature code base. Less mature technologies that could be considered include the anygui project and the IBM Eclipse library and IDE. The anygui project is very much in the early research stage, with a minimal set of widgets defined. It would be great as the standard GUI API because it would allow the user to select the underlying GUI toolkit at execution time. When anygui eventually matures it could be added to the standard library, alongside the Tkinter and whatever other GUI APIs find their way into the standard distribution. The IBM Eclipse GUI was written for Java, but the C language interface, which is a thin layer over native toolkit widgets, could be wrapped into a Python GUI package. The design goals described in the design methodology provide a well balanced tradeoff in Eclipse is to use the native widgets when they are available and build widgets that are missing from native components. This fixes the problems with the Java awt (lowest common denominator widgets) and Swing (draws all widgets using Java). While Eclipse looks attractive, it is not as mature as the other options and it has not gathered a strong following of Python users. In addition to the GUI, I think it is important to have a GUI Builder available for the GUI toolkit. This has always been a weakness of Tkinter and I think it has hurt the growth of Python that we did not have a visual basic like GUI interface for building applications. By selecting PyGtk, and including the libglade library, it would be easy to create an integrated development environment based on Glade and the XML glade files that it generates. Quality tools such as these need to be part of the standard distribution. If they are not then they cannot be counted on to be part of a Python installation. I have seen numerous programs written in Tkinter simply because the author did not want to impose the requirement of installing an alternative GUI library. Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package is probably the closest match to the Python coding philosophy and style. It is also closer to the Tkinter programming model. PyGtk is written in C and the widget library seems to be a superset of Tkinter. I also think James has done an excellent job of making use of the Python 2.2 API for creating classes. The library has a very natural Python feel to it. Would others on this list care to comment on this assertion? The case for adding a new GUI to the standard library will need to address the sticky point of why the GUI toolkit is appropriate for the standard Python library. An argument often posed for using wxPython instead of PyGtk has been that wxPython used native widgets to render applications on platforms. This allows the GUI themes of the native toolkit to be transparently used in the application. This helps make the application look closer to the users expectations for the GUI. There is merit to this argument, but the tradeoff is a more bloated GUI toolkit that places abstraction layers inbetween a native toolkit and the GUI API. It looks like some work has been done on making the native themes for Windows and Mac OS X [1] work under Gtk+ [2]. Is anyone on this list experienced with using these capabilities? Do they mitigate the theme problems of Gtk+, or will applications still need to manually adjust the themes to match the theme of their desktop? I'd like to get some feedback from this list before brining this idea up in the general python mailing list. If it is shot down here, where I would expect some support for selecting PyGtk, there is no need to take up the bandwidth of the larger forum. If Guido rejects adding a new GUI package into the standard distribution, then I would suggest that we use PyGtk as one of the foundation packages in a Fat Python distribution. The purpose of developing Fat Python is to provide users with a "No Assembly Required" distribution of Python. It would be a release of a set of Python packages and applications that run cross-platform. The goal would be to create binary installations for major platforms. [1] http://www.osxfaq.com/Press/12-31-02/gtk-12-31-02.ws [2] http://gtk-wimp.sourceforge.net/ _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
