Re: ANNOUNCE: pygtk-1.99.8

[Thomas Leonard <tal00r ecs soton ac uk>]

On Thu, Mar 21, 2002 at 09:22:38PM +0800, James Henstridge wrote:
> Thomas Leonard wrote:
> 
> >James Henstridge <james daa com au> wrote:
> >
> >>I have uploaded a pygtk-1.99.8 tarball, which will work with the 2.0 
> >>release of gtk+.  It is still not quite release quality, but it is 
> >>getting there.
> >>
> >
> >Very nice. I like the interface much better than the 1.2 one. However, I'm
> >still worried about backwards compatibility. I have quite a lot of pygtk
> >1.2 programs (sketch, pythontheater, pysol, etc), and I've written many of
> >my own which are now installed on other people's computers.
> >
> I have explained this to you before.  The difference between the C and 
> Python is that the names of modules are part of the API.  Changing a 
> module name means doing many changes to many pieces of source code. 

Python source or pygtk source? I was hoping the changes to both would be
minor. As far I can see, changing a python program means, eg:

	import gtk
	w = gtk.Window()
	...

would become

	from gtk2 import gtk
	w = gtk.Window()
	...

ie, only the first line of each file would need to change. I haven't
looked too closely at the pygtk source, but I can't imagine the changes
would be very far-reaching?

[ gtk.Window -> gtk.GtkWindow ]

> People have been asking for this change for years.  The switch to 2.0 
> gave an opportunity to fix many of the problems with pygtk's 
> infrastructure.  The new codebase is much more maintainable, and 
> hopefully nicer to use.

Absolutely. The new system is great, except that it breaks all existing
code (2.0 would be incompatible anyway, this was just the simplest example
of a correctly written program that breaks when the new version is
installed).

[...]
> >- Make our own distribution of pygtk using the module name 'gtk2', and
> > write our programs to use that. This is good in the short term, but it
> > means more installing work for users who have also installed the
> > official package.
> >
> Or install pygtk in a private directory, along with the rest of the 
> modules in your program.  Use a shell script to launch your program, and 
> set PYTHONPATH appropriately.

Yes, this is what our distribution would do (install into a 'gtk2'
subdirectory). Not sure we need to set environment variables if 'gtk2' is
in the standard search path?

[...]
> >Also, both of the first two options leave us open to everything breaking
> >again when 3.0 comes out.
> >
> I doubt the changes to pygtk will be as drastic when we move over to 3.0 
> (whenever that happens).  I am a lot happier with the new codebase, and 
> think it will adapt well in the future.

3.0 will be an incompatible API change (otherwise, it'll be 2.x), so
presumably things *will* break.

> >How are the other bindings authors dealing with this? Also, what are
> >packagers planning to do? I can't imagine Debian is going to allow an
> >incompatible upgrade, for example?
> >
> Please come up with some new suggestions w.r.t. parallel install issue. 
> I have given you reasons why I won't change the module name, and given 
> several options about how parallel installs may be done, but you seem be 
> ignoring them.

As an application author, I need to be able to distribute programs that
users can run. Eg, say I want a program that just opens a window. Under
1.2, I would write something like:

	#!/usr/bin/env python
	import gtk

	w = gtk.GtkWindow()
	w.show()
	w.connect('destroy', gtk.mainquit)
	gtk.mainloop()

This is a nice little program that users can just click on to run. I can't
see any way to write this in 2.0, unless there is a standard location for
the 2.0 bindings (eg, as described above).

> James.
> 
> (who wonders what people would have thought if they were told to run sed 
> 's/Gtk/Gtk2/g;s/gtk/gtk2/g' on their C programs to upgrade to gtk 2.0)

It's more like having to change 'gtk-config' to 'pkg-config gtk+-2.0' in
all their Makefiles...


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r ecs soton ac uk		tal197 users sourceforge net