Re: [pygtk] Compiled versions of _gtk.pyd and libglade.pyd forPython2.1.1
On Thu, 18 Oct 2001, Christian Robottom Reis wrote: On Thu, 18 Oct 2001, Rodrigo Senra wrote: of those ? I have pygtk-0.6.8 all set, but I am having some problems with these 2 DLLs. There were supposed to be precompiled pygtk versions at http://hans.breuer.org/ports/default.htm Python 1.5.2 and 2.0 only. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL). ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
On Thu, Oct 18, 2001 at 12:57:04AM -0200, Rodrigo Senra wrote: Does anybody still use glc.py ? If not, what do you use instead to generate code templates from glade (if you do) ? Just an FYI, since you asked, I am using gladepyc to generate the main part of the GUI I'm building, along with a few custom on-the-fly widgets directly from pyGTK. The gladepyc code operates mainly on the _gtk level, and builds a fairly monolithic object, but this is more than adequate for the mostly-static parts of the interface. -- A. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] What are the restrictions on hanging new signals on the widget tree?
Using the Gtk 2.0 API, I have a subclass of GtkEntry to which I've attached three new signals: history-prev, history-next, and history-menu: class _HEntry(gtk.Entry): def __init__(self, *args): gtk.Entry.__init__(self, *args) self.set_name(_history_) gobject.signal_new(history-prev, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-next, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-menu, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) I want to add the same signals to a subclass of GtkSpinButton: class _HSpinButton(gtk.SpinButton): def __init__(self, *args): gtk.SpinButton.__init__(self, *args) self.set_name(_history_) gobject.signal_new(history-prev, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-next, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-menu, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) When I try this, the signals seem to be defined for my GtkEntry subclass just fine, but I get a Gtk warning and Python RuntimeError exception when trying to attach the signals to the GtkSpinButton subclass: History.py (pid:18736): GRuntime-WARNING **: gsignal.c:1147:g_signal_newv(): signal history_prev already exists in the `GtkEntry' class ancestry Traceback (most recent call last): ... File /home/skip/src/tttech/projects/SW/lib/python/TGW/Spinner.py, line 19, in ? gobject.TYPE_NONE, ()) RuntimeError: could not create signal This is a bit frustrating. I thought the restriction on signal names was that a direct ancestor of the class to which I was adding a signal couldn't already be using this signal name. It seems to me that I need to add these three signals rather high up in the widget hierarchy, which unfortunately will pollute a lot of widgets that have no use for them with these signals. Is there an alternative? Thx, Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] What are the restrictions on hanging new signals on the widget tree?
Skip Montanaro wrote: Using the Gtk 2.0 API, I have a subclass of GtkEntry to which I've attached three new signals: history-prev, history-next, and history-menu: class _HEntry(gtk.Entry): def __init__(self, *args): gtk.Entry.__init__(self, *args) self.set_name(_history_) gobject.signal_new(history-prev, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-next, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-menu, _HEntry, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) The above code creates a python subclass of GtkEntry, but at the C level (where all the signal handling takes place), your _HEntry is still just a GtkEntry (take a look at _HEntry.__gtype__). At the moment, you need to explicitly create a new GType for your subclass. Your _HEntry def should look like: class _HEntry(gtk.Entry): def __init__(self): gobject.GObject.__init__(self) self.set_name(_history_) gobject.type_register(_HEntry) Note the gobject.type_register() call, and chaining to GObject.__init__ rather than gtk.Entry.__init__. If you look at _HEntry.__gtype__, it should be for This way, the signals will be added to your new type rather than GtkEntry. This will also change the type name used in the gtkrc file. The type name is generated from the full class name (module.class), with dots replaced with plus signs (because Tim doesn't want to make dots valid in type names). I want to add the same signals to a subclass of GtkSpinButton: class _HSpinButton(gtk.SpinButton): def __init__(self, *args): gtk.SpinButton.__init__(self, *args) self.set_name(_history_) gobject.signal_new(history-prev, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-next, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) gobject.signal_new(history-menu, _HSpinButton, gobject.SIGNAL_RUN_LAST|gobject.SIGNAL_ACTION, gobject.TYPE_NONE, ()) GtkSpinButton is a GtkEntry, and your above code added the signals to GtkEntry (so they are visible in GtkSpinButton). Registering a new type for _HSpinButton is probably the right option here as well. When I try this, the signals seem to be defined for my GtkEntry subclass just fine, but I get a Gtk warning and Python RuntimeError exception when trying to attach the signals to the GtkSpinButton subclass: History.py (pid:18736): GRuntime-WARNING **: gsignal.c:1147:g_signal_newv(): signal history_prev already exists in the `GtkEntry' class ancestry Traceback (most recent call last): ... File /home/skip/src/tttech/projects/SW/lib/python/TGW/Spinner.py, line 19, in ? gobject.TYPE_NONE, ()) RuntimeError: could not create signal This is a bit frustrating. I thought the restriction on signal names was that a direct ancestor of the class to which I was adding a signal couldn't already be using this signal name. It seems to me that I need to add these three signals rather high up in the widget hierarchy, which unfortunately will pollute a lot of widgets that have no use for them with these signals. Is there an alternative? Does the above comments help? See the examples/gobject/signals.py program for an example of registering new types. James. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)
Hello Rodrigo, I'm the guy who wrote gladepyc. On Thursday, 18 October 2001, you (Rodrigo Senra) wrote: ... Cool tip about gladepyc, is there a good reason for the absence of a link to this project in PyGTK Home Page ? Good idea. Don't know why, I didn't think about it before. However I just had a look on PyGTK home and links pages, and GLC does not appear there either. A long time ago I have submitted the link to Glade's author (Damon Chaplin), so that it would appear on Glade's links page, which is where I initially found GLC; Unfortunately the link still hasn't appeared. On the other hand, James is the author of both PyGTK and libglade, and the latter is being promoted vigorously (as you saw in the first answer :-). Not sure James is willing to add a link to a concurrent product ;) -- Hope this helps, Fabien. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] What are the restrictions on hanging new signals on the widget tree?
James class _HEntry(gtk.Entry): James def __init__(self): James gobject.GObject.__init__(self) James self.set_name(_history_) James gobject.type_register(_HEntry) James Note the gobject.type_register() call, and chaining to James GObject.__init__ rather than gtk.Entry.__init__. If you look at James _HEntry.__gtype__, it should be for This way, the signals will be James added to your new type rather than GtkEntry. This will also James change the type name used in the gtkrc file. The type name is James generated from the full class name (module.class), with dots James replaced with plus signs (because Tim doesn't want to make dots James valid in type names). Thanks, I never would have guessed that. How come there is no need to chain through gtk.Entry.__init__? James Does the above comments help? Yes, thanks. (My other alternative was to hang my new signals off gtk.Widget...) Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
