One request that has come up many times is to drop the "Gtk" prefix from
the widget class names in pygtk.
In the past, the answer has been that it would cause name space pollution
for people doing "from gtk import *". However for the development series,
using "from gtk import *" is discouraged more so than in the stable series
(when the development branch goes stable, I intend to have all examples
converted over to using "import gtk").
As this would cause large source incompatibility, I am looking for
people's opinions about such a change (I haven't decided which way I feel
about this issue yet).
To help people get a feel for the two options, I made the required
modifications to pygtk on a branch in CVS (short-class-names-branch),
converted the pygtk-demo example over and spun a tarball of the result.
It is available here:
http://www.gnome.org/~james/pygtk-1.99-short-class-names.tar.gz
It is identical to the 1.99 release (other than the class naming), so
should compile and run with the 1.3.7 release of gtk+.
The main changes are:
pango.Pango* -> pango.*
gtk.Gtk* -> gtk.*
gtk.Gdk* -> gtk.gdk.*
and the functions in the gtk module that were from GDK have been moved to
gtk.gdk module.
There is one other major change that I am considering (although it will
affect the API far less) -- using the new python 2.2 features instead of
ExtensionClass. I haven't started looking at how easy such a change would
be (probably not that hard -- it would mainly be changes to the code
generator and the gobject module). The change would have the following
pros:
- no longer require ExtensionClass. The current development version of
pygtk requires a modified version of ExtensionClass (that allows
creating subclasses in C). This ExtensionClass is not currently in
sync with the Zope version, as I haven't been able to get the changes
merged back in. ExtensionClass often needs to be updated to support
new python releases.
- Using the native class support in python 2.2 will probably integrate
better with python (there are a number of gotchas when using
ExtensionClass).
Cons are:
- Require python 2.2. Older versions of python won't work. (of course,
most Linux distros are still shipping 1.5.2 as the default python
installation. By the time Red Hat, etc make a binary compatibility
breaking release, 2.2 should be out).
- Some currently used ExtensionClass features may not have equivalents
in Python 2.2's new code.
Comments on this issue are also welcomed (keeping in mind that I haven't
even started testing it on a branch yet).
James.
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
