On Monday 24 March 2003 10:43 am, James Henstridge wrote: > I don't know. PyGTK is a fairly large extension compared to most other > extensions distributed with Python (mostly due to the size of the GTK > API). I don't know what the Python developers would think of something > of its size. > > The other reservation I have is release frequency. PyGTK is still being > improved with each release, and those releases are much closer together > than Python releases.
I envision having PyGtk continue to develop independent of Python, like PyXML and IDLE have parallel development tracks. The point would be do declare an enndorsed winner in the standard GUI for Python and bundle the GUI with the standard distribution. > From a quick look at the anygui documentation, it doesn't seem to be a > very interesting GUI programming API. It looks like it uses absolute > positioning for pretty much everything, which is a big step backwards > compared to the geometry management of GTK, Qt and Tk, etc. Fair enough. I only brought up anygui because it is an interesting attempt to unify the GUI across by supporting all possible GUI interfaces. It was mentioned more to acknowledge the effort than to endorse the API. I'd primarily interested in having a single tight API become the Python standard GUI. Of the big three, I think PyGtk is most Pythonic, which is what I stated in the following paragraph. > >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. > The gtk-osx project you mention here is not really relevant to PyGTK in > its current form. Since the developers main aim was to have a toolkit > to run filmgimp on OS X, they decided to port GTK 1.2. This means that > the port is can not be used to port any modern GTK application to OS X > (remember that GTK 1.2 has now been obsoleted by two stable series > now). It also means that gtk-osx can't take advantage of the backend > separation work that was done during GTK 2.0 and 2.2 development in > order to make ports easier. This is my opinion, of course. > > As far as the gtk-wimp theme engine, it would be pretty easy to do a GTK > distribution for windows that had it set as the default theme engine. > It is really just a packaging issue. Thanks for clearing this up for me. My point was to identify some process in which PyGtk could be made available with a native theme for all three of the major platforms: X Windows, Windows, and Mac OS X. As I said in an earlier posting, it will be a requirement to identify maintainer for the three platforms before standardizing on PyGtk would even be considered in the standard Python distribution. I think it is important to establish a robust standard GUI API for Python. I don't really care which one is selected. PyGtk seems to be the best candidate. We need to pick one and move on with it. Back at the Python Conference in Menlo Park in 1995 we had a BOF to discuss standardizing the GUI for Python. Guido said something to the effect of "Let many flowers grow in the garden". That was 8 years ago. It's time to weed the garden. Python is being hurt by not having a stronger default GUI included in the standard distribution. > >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. > > My main concern would be linking of the release schedules. It isn't > clear that linked release schedules would benefit either pygtk or python. The releases do not have to be linked, but each Python release should include the most up to date PyGtk release so the end users have something better than Tkinter to count on being included in the distribution. To make this happen we need better documentation and designated maintainers for the three major platforms. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
