unsubscribe On Thu, Sep 13, 2001 at 12:39:00AM +0800, [EMAIL PROTECTED] wrote: > Send pygtk mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.daa.com.au/mailman/listinfo/pygtk > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pygtk digest..." > > > Today's Topics: > > 1. Re: GnomeHRef causing crash, but never used (Christian Robottom Reis) > 2. Request for Comments: shorter widget class names (James Henstridge) > 3. Re: Canvas group add problems (Tjabo Kloppenburg) > 4. custom sort of GtkCList (Ali Graham) > 5. Re: Request for Comments: shorter widget class names (Christian Tanzer) > 6. Re: custom sort of GtkCList (Christian Robottom Reis) > 7. Re: Request for Comments: shorter widget class names (Christian Robottom Reis) > 8. Re: Request for Comments: shorter widget class names (Fabien COUTANT) > 9. Re: Request for Comments: shorter widget class names (Tom Cato Amundsen) > 10. Re: Canvas group add problems (Christian Robottom Reis) > 11. Re: Questions about CList (Christian Robottom Reis) > 12. Re: PATCH: implementing window members (Christian Robottom Reis) > 13. Re: Request for Comments: shorter widget class names (Skip Montanaro) > > --__--__-- > > Message: 1 > Date: Wed, 12 Sep 2001 02:20:21 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: Don Allingham <[EMAIL PROTECTED]> > Cc: PyGTK List <[EMAIL PROTECTED]> > Subject: Re: [pygtk] GnomeHRef causing crash, but never used > > On 9 Sep 2001, Don Allingham wrote: > > > Any idea as to what could be causing this? Is there some way to catch > > the errors and find out where in the python code this is being > > triggered? > > One idea is running python through gdb and pasting a traceback into a mail > message; it does make crashes easier to spot. I'm not quite sure where > this is being called, but the backtrace will show where orbit-python makes > it's call. > > > GnomeUI-CRITICAL **: file gnome-href.c: line 96 (gnome_href_new): assertion `url >!= NULL' failed. > > > > Gtk-CRITICAL **: file gtkwidget.c: line 3198 (gtk_widget_set_name): assertion >`widget != NULL' failed. > > > > Gtk-CRITICAL **: file gtkwidget.c: line 3782 (gtk_widget_set_usize): assertion >`widget != NULL' failed. > > > > Gtk-CRITICAL **: file gtkwidget.c: line 3306 (gtk_widget_set_sensitive): assertion >`widget != NULL' failed. > > > > Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' > > > > > > > > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 2 > Date: Wed, 12 Sep 2001 13:56:46 +0800 (WST) > From: James Henstridge <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: [pygtk] Request for Comments: shorter widget class names > > 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. > > > --__--__-- > > Message: 3 > Date: Tue, 11 Sep 2001 10:42:57 +0200 > From: Tjabo Kloppenburg <[EMAIL PROTECTED]> > Organization: billiton internet services > To: Rob Brown-Bayliss <[EMAIL PROTECTED]> > Cc: PyGTK List <[EMAIL PROTECTED]> > Subject: Re: [pygtk] Canvas group add problems > > Rob Brown-Bayliss wrote: > > > > hi > > > > I am plying with the gnome canvas, and having a problem adding images. > > > > This works: > > > why isn't there a ReplyTo-tag to the list in the mail headers? > > > but if I do: > > item = group.add("image" , ... ) > > I get the error: > > TypeError: add() takes exactly 2 arguments (X given) > > where X is the number of args I gave. > > I think one of the two arguments is "self". When it says "takes exactly > two arguments" it > means "self" and "another". > > tk. > > -- > Tjabo Kloppenburg - billiton internet services GmbH > Entwicklung > > telefon: (0271) 30386-19 *** email: [EMAIL PROTECTED] > Weitere Informationen finden Sie unter http://www.billiton.de/ > > --__--__-- > > Message: 4 > Date: Tue, 11 Sep 2001 22:45:14 +0930 > From: Ali Graham <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Organization: Cosmonaut Web Factory > To: [EMAIL PROTECTED] > Subject: [pygtk] custom sort of GtkCList > > > is it possible to do this? set_compare_func doesn't seem to be implemented. > > at the moment my idea is to use the code below, doing a full freeze() / sort > (respecting all of the GTK settings if possible) / thaw(). I'm trying to write a > file manager, and thus want directories to be separate from the files... > > class GtkCListSortable(GtkCList): > > def __init__(self, num_cols, names): > > self.compare_func = 0 > > GtkCList.__init__(self, num_cols, names) > > def sort(self): > > if self.compare_func != 0: print "do a custom sort here" > else: GtkCList.sort(self) > > def set_compare_func(self, func): > > self.compare_func = func > > Maybe someone has done somthing similar already? > > I'm not subscribed to the list, sorry, so please CC replies to me as well as to > the list :) > > ali. > > > --__--__-- > > Message: 5 > To: James Henstridge <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [pygtk] Request for Comments: shorter widget class names > Reply-To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Christian Tanzer) > Date: Wed, 12 Sep 2001 09:01:52 +0200 > > > > One request that has come up many times is to drop the "Gtk" prefix fro= > m > > the widget class names in pygtk. > > = > > > In the past, the answer has been that it would cause name space polluti= > on > > for people doing "from gtk import *". However for the development seri= > es, > > using "from gtk import *" is discouraged more so than in the stable ser= > ies > > (when the development branch goes stable, I intend to have all examples= > > > converted over to using "import gtk"). > > I consider `from gtk import *` to be evil (having myself suffered by > innocently using `from Tkinter import *`). > > IMHO, `gtk.Button` is much better than either `GtkButton` or > `gtk.GtkButton`. > > > 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 fe= > el > > about this issue yet). > > I guess it's either now or never. > > > 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 o= > f > > ExtensionClass. I haven't started looking at how easy such a change wo= > uld > > be (probably not that hard -- it would mainly be changes to the code > > generator and the gobject module). > > Using 2.2 would be a good thing. OTOH, 2.2 isn't really here yet. > > Personally, I'm in favor of switching as fast as possible. Yet, a > forced switch to 2.2 might make many people seriously unhappy > (including me). > > -- = > > Christian Tanzer [EMAIL PROTECTED]= > at > Glasauergasse 32 Tel: +43 1 876 62 = > 36 > A-1130 Vienna, Austria Fax: +43 1 877 66 = > 92 > > > --__--__-- > > Message: 6 > Date: Wed, 12 Sep 2001 04:24:13 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: [pygtk] custom sort of GtkCList > > > On Tue, 11 Sep 2001, Ali Graham wrote: > > > is it possible to do this? set_compare_func doesn't seem to be implemented. > > I implement custom sorting in Kiwi (specifically, sorting for > int/float/string contents, but it should be easily extended): > > http://www.async.com.br/kiwi/Kiwi-0.4.1.tar.gz > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 7 > Date: Wed, 12 Sep 2001 04:31:10 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: James Henstridge <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: [pygtk] Request for Comments: shorter widget class names > > On Wed, 12 Sep 2001, James Henstridge wrote: > > > One request that has come up many times is to drop the "Gtk" prefix from > > the widget class names in pygtk. > > Very briefly (since I need to sleep badly): James, this is a great idea, > and I do hope you decide on it. I remember this was the one thing that > turned me off in using python and gtk together; the name prefixing seemed > like a kludge. I don't care if it breaks all my code; I really vote for > it. The precedent is there - tkinter is an example of no prefixing and > it's been around and standard for a while. This is a great idea. > > > The main changes are: > > pango.Pango* -> pango.* > > gtk.Gtk* -> gtk.* > > gtk.Gdk* -> gtk.gdk.* > > /me grins and hopes > > > 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 > > Is pushing up the requirement for pygtk2 to Python2.2 reasonable? > > If you feel it is, I definitely support the shift. IMO it's perfectly sane > -- "if you want cutting edge gtk2, you're required to upgrade to > python22." Python2.2 has interesting news (iterators and type > subclassing, yum), and very little of it will cause serious problems for > legacy applications. I don't think a distribution issue should be the > standoff here. > > Take care, > -- Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 8 > Date: Wed, 12 Sep 2001 09:54:02 +0200 > From: Fabien COUTANT <[EMAIL PROTECTED]> > To: James Henstridge <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [pygtk] Request for Comments: shorter widget class names > > Hello everybody, > > On Wednesday, 12 September 2001, you (James Henstridge) wrote: > > One request that has come up many times is to drop the "Gtk" prefix from > > the widget class names in pygtk. > ... > > 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). > > I'm pretty in favor of it. Seems cleaner and more Pythonish. I always > wondered why the module name is repeated as prefix for all functions, > because the way you propose now seems so more simpler. > > Additionally, changes required to existing sources are not so difficult: > should just be a matter of subsituting "gtk." for "gtk_" and adjusting > import statements. > > ... > > and the functions in the gtk module that were from GDK have been moved to > > gtk.gdk module. > > Here, having separate modules for each prefix may be more appropriate. > I prefer writing "gdk.something" rather than "gtk.gdk.something"; OTOH I > could as well change my import statement to "import gtk; from gtk import > gdk" and go on using the first form. > > This is a bigger problem for constants: "GTK.CONSTANT" is more readable > than "gtk.CONSTANT", but I know having a "GTK" module beside "gtk" > raises case problems on some "platform". > > I'm confident there is a module organization that makes things appear > clean to the developper about all aspects. > > > 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 > ... > > I see another advantage: as time passes, more features will be added to > this Python mechanism, and using the standard way to do things will allow > PyGtk to benefit from new features with minor or no changes to it (since > Python's APIs are traditionally more stable). > There still are problems with ExtensionClass, and one can hope that > Python's own implementation will work more seamlessly, sooner or later. > > -- > Hope this helps, > Fabien. > > --__--__-- > > Message: 9 > From: "Tom Cato Amundsen" <[EMAIL PROTECTED]> > Date: Wed, 12 Sep 2001 11:58:00 +0200 > To: [EMAIL PROTECTED] > Subject: Re: [pygtk] Request for Comments: shorter widget class names > > On Wed, Sep 12, 2001 at 01:56:46PM +0800, James Henstridge wrote: > > One request that has come up many times is to drop the "Gtk" prefix from > > the widget class names in pygtk. > > > I'm positive to this. A little perl^H^H^ython script can do most of the > conversion. And programs has to be ported to pygtk anyway. > > > 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). > I'd say go for it. But then I only maintains some 10k lines of > noncritical already buggy code... The faster 1.5.2 get dumped the better. > > One negative thing is that python 2.2 will probably not make it into > woody. > > > > James. > > > > _______________________________________________ > > pygtk mailing list [EMAIL PROTECTED] > > http://www.daa.com.au/mailman/listinfo/pygtk > > > > -- > Tom Cato Amundsen <[EMAIL PROTECTED]> > GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/ > > --__--__-- > > Message: 10 > Date: Wed, 12 Sep 2001 10:50:09 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: Tjabo Kloppenburg <[EMAIL PROTECTED]> > Cc: Rob Brown-Bayliss <[EMAIL PROTECTED]>, > PyGTK List <[EMAIL PROTECTED]> > Subject: Re: [pygtk] Canvas group add problems > > On Tue, 11 Sep 2001, Tjabo Kloppenburg wrote: > > > why isn't there a ReplyTo-tag to the list in the mail headers? > > Because they are evil, and you should CC: the list on your answer. > > > > TypeError: add() takes exactly 2 arguments (X given) > > > where X is the number of args I gave. > > > > I think one of the two arguments is "self". When it says "takes exactly > > two arguments" it > > means "self" and "another". > > IIRC, this numbering issue was fixed in the latest pygtk. > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 11 > Date: Wed, 12 Sep 2001 11:07:16 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: Lionel Ulmer <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: [pygtk] Questions about CList > > On Thu, 6 Sep 2001, Lionel Ulmer wrote: > > > My big problem now is that when I move the row displayed (using move_to), > > the row that is focused does NOT move with it. This means that when I later > > page-up or page-down, I move from the previously selected row and NOT from > > the position I see on the screen. > > Yep, have the same problem. :/ James, any ideas? > > > - be able to modify the 'focus_row' field of the GtkCList object. I do not > > know if this is possible via Python ? > > Hmm, there is a toggle_focus_row; tried using it? > > > - somehow 'grab' the page-up and page-down keys before they are sent to the > > CList and implement them myself. > > This is doable (just catch key_press_event and emit_stop_by_name() in the > handler) but I'm not sure it would solve the problem. > > > I really regret that there is no way to have a 'SELECTION_NONE' mode for the > > CList.... > > Hah! Me too. :) You can make it insensitive, you know, but that changes > the font colour. > > > BTW, another misc. question : how can I get the parent of a widget in the > > widget hierarchy ? > > FAQ alert, James! :) > > widget['parent'] - yep, it's quite odd. > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 12 > Date: Wed, 12 Sep 2001 11:21:41 -0300 (BRT) > From: Christian Robottom Reis <[EMAIL PROTECTED]> > To: James Henstridge <[EMAIL PROTECTED]> > Cc: Skip Montanaro <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > Subject: Re: [pygtk] PATCH: implementing window members > > On Wed, 12 Sep 2001, James Henstridge wrote: > > > Having it in bugzilla is useful. It is a lot harder to lose bugs/patches > > that have been submitted to bugzilla. > > Bug 60419 filed. More to come :) > > Take care, > -- > Christian Reis, Senior Engineer, Async Open Source, Brazil. > http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL > > > --__--__-- > > Message: 13 > From: Skip Montanaro <[EMAIL PROTECTED]> > Date: Wed, 12 Sep 2001 11:36:25 -0500 > To: James Henstridge <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: [pygtk] Request for Comments: shorter widget class names > Reply-To: [EMAIL PROTECTED] (Skip Montanaro) > > > James> One request that has come up many times is to drop the "Gtk" > James> prefix from the widget class names in pygtk. > > I have no strong opinion on this topic, but would generally favor it. > > James> There is one other major change that I am considering (although > James> it will affect the API far less) -- using the new python 2.2 > James> features instead of ExtensionClass. I haven't started looking at > James> how easy such a change would be (probably not that hard -- it > James> would mainly be changes to the code generator and the gobject > James> module). The change would have the following pros: > > This I am more strongly in favor of. ExtensionClass will likely need some > tweaks to run with 2.2. Guido mentioned this on python-dev. He also > indicated that one goal of the type/class unification was to eliminate > ExtensionClass altogether. My guess is that it's unlikely that the Zope > folks will support ExtensionClass beyond the 2.2 release, so I think it > would be best to bite the bullet now and get rid of EC now. > > -- > Skip Montanaro ([EMAIL PROTECTED]) > http://www.mojam.com/ > http://www.musi-cal.com/ > > > --__--__-- > > _______________________________________________ > pygtk mailing list > [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > > > End of pygtk Digest _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
