Re: [pygtk] feature request: binding for gtk_propagate_event?
On Wed, Nov 13, 2002 at 03:35:42PM +0800, James Henstridge wrote: A single signal emission will only call handlers attached to the object it was emitted on. The propagation of events up the heirachy is acheived by emitting the signal a number of times. For events such as the button presses and motion events, the event is delivered first to the widget the event occurred in. It will emit the appropriate event signal. If the event signal returns false (indicating that the event hasn't been handled), then a signal will be emitted on the parent. This continues all the way up to the toplevel if no one handles the event. Keyboard events are handled differently. When your window receives a keyboard event, it is first dispatched to the toplevel window, which will check if it matches any keyboard shortcuts. If the key press doesn't match a shortcut, then the event is dispatched to the child widget that currently has focus. - FAQ 3.11. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
With gtk1/gnome1, binding the signals seems to happen when a widget-tree is added to the AppletWidget container. So, if you add Buttons to a GtkHBox, and then add that box to the AppletWidget, the button-events are processed by the panel. If you first add the GtkHBox, and then add the buttons to the GtkHBox, then those buttons receive events button2 and button3. Some explicit mechanism for gnome2 to bind the signals would be better. Hmm, interesting that you mention this layout, because I just tried the same hack with a different applet (one that puts a GtkButton and a GtkProgressBar into a VBox, then the VBox in the applet), and in this case the hack does not help. I suspect the signals are being sent to the VBox, which ignores them. So the menu is accessible by button3 from within the progress bar, but not from the button (just as it without the parent.emit hack). Am I right in thinking that events are propagated backwards (from window to parent window and so on up to the root window) until somebody claims them, but that gtk signals are not? That might be why the gnome-applets authors used gtk_propagate_event instead of re-emitting signals: the immediate parent might not be the appropriate recipient. More ideas are most welcome.. thanks, -Brian ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
On Tue, Nov 12, 2002 at 08:33:20AM +0100, Andreas Degert wrote: With gtk1/gnome1, binding the signals seems to happen when a widget-tree is added to the AppletWidget container. So, if you add binding the signals? Do you mean connect() itself, or something else? Buttons to a GtkHBox, and then add that box to the AppletWidget, the button-events are processed by the panel. If you first add the GtkHBox, and then add the buttons to the GtkHBox, then those buttons receive events button2 and button3. Some explicit mechanism for gnome2 to bind the signals would be better. I'm not entirely sure I understand (or agree) with what you describe? It could just be that the hierarchy through which the signal propagates is killing the signal somewhere, or some handler is not doing what it should. AFAIK, it shouldn't matter at all the order in which the widgets are composed. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
On Tue, Nov 12, 2002 at 01:04:40AM -0800, Brian Warner wrote: Am I right in thinking that events are propagated backwards (from window to parent window and so on up to the root window) until somebody claims them, but that gtk signals are not? That might be why the gnome-applets authors used gtk_propagate_event instead of re-emitting signals: the immediate parent might not be the appropriate recipient. I have no idea; from the tutorial it does say that this is for all signals, but only cites as example an _event signal. http://www.gtk.org/tutorial/sec-signalemissionandpropagation.html It could just be that there is a default handler somewhere that gobbles the signal up (returns gtk.TRUE), which is why the authors work around it. Or it could be something else :) Owen definitely knows the answer, as does gtk+-2.0.4.tar.gz ;-) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
Christian Reis [EMAIL PROTECTED] writes: On Tue, Nov 12, 2002 at 08:33:20AM +0100, Andreas Degert wrote: With gtk1/gnome1, binding the signals seems to happen when a widget-tree is added to the AppletWidget container. So, if you add binding the signals? Do you mean connect() itself, or something else? Buttons to a GtkHBox, and then add that box to the AppletWidget, the button-events are processed by the panel. If you first add the GtkHBox, and then add the buttons to the GtkHBox, then those buttons receive events button2 and button3. Some explicit mechanism for gnome2 to bind the signals would be better. I'm not entirely sure I understand (or agree) with what you describe? It could just be that the hierarchy through which the signal propagates is killing the signal somewhere, or some handler is not doing what it should. AFAIK, it shouldn't matter at all the order in which the widgets are composed. ok, I took some time and checked it with the source. All of this is only valid for gtk1 and gnome1 (at least I haven't checked what changed in gnome2). The class AppletWidget in module applet.py has a method add_full to add the widget-tree for the applet into the AppletWidget: add_full(self, child, bind_events) This corresponds to the c-function applet_widget_add_full in the file applet-widget.c. bind_events is a boolean parameter. If set, the function bind_applet_events is called at the end of function. It recursivly connects the signal-handler applet_event to the signal event to each widget (with a window) in the widget-tree. The python method add is equivalent to add_full with bind_events set to true. There is also a separate method bind_events. So, it seems to be cleaner to call add_full with the bind-events parameter set to false, and then call bind_events explicitely at some point, because it affects all widgets it finds in the tree. If you use add, you get the order-dependency as a consequence of that side-effect. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
Brian Warner wrote: With gtk1/gnome1, binding the signals seems to happen when a widget-tree is added to the AppletWidget container. So, if you add Buttons to a GtkHBox, and then add that box to the AppletWidget, the button-events are processed by the panel. If you first add the GtkHBox, and then add the buttons to the GtkHBox, then those buttons receive events button2 and button3. Some explicit mechanism for gnome2 to bind the signals would be better. Hmm, interesting that you mention this layout, because I just tried the same hack with a different applet (one that puts a GtkButton and a GtkProgressBar into a VBox, then the VBox in the applet), and in this case the hack does not help. I suspect the signals are being sent to the VBox, which ignores them. So the menu is accessible by button3 from within the progress bar, but not from the button (just as it without the parent.emit hack). Am I right in thinking that events are propagated backwards (from window to parent window and so on up to the root window) until somebody claims them, but that gtk signals are not? That might be why the gnome-applets authors used gtk_propagate_event instead of re-emitting signals: the immediate parent might not be the appropriate recipient. A single signal emission will only call handlers attached to the object it was emitted on. The propagation of events up the heirachy is acheived by emitting the signal a number of times. For events such as the button presses and motion events, the event is delivered first to the widget the event occurred in. It will emit the appropriate event signal. If the event signal returns false (indicating that the event hasn't been handled), then a signal will be emitted on the parent. This continues all the way up to the toplevel if no one handles the event. Keyboard events are handled differently. When your window receives a keyboard event, it is first dispatched to the toplevel window, which will check if it matches any keyboard shortcuts. If the key press doesn't match a shortcut, then the event is dispatched to the child widget that currently has focus. James. -- Email: [EMAIL PROTECTED] | Linux.conf.au http://linux.conf.au/ WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
On Sun, Nov 10, 2002 at 03:24:49PM -0800, Brian Warner wrote: The net result is that, in the applets I write that contain buttons, it is difficult to get to the applet's context menu (to configure or remove the applet). If the applet is all button, it is impossible. Several of standard Gnome applets (in gnome-applets-2.0.3), drivemount and mini-commander in particular, have a hack to work around this. The hack adds a signal handler to the GtkButton which catches button2/button3 and uses gtk_propagate_event() to send the event off to the applet as a whole, which responds by putting up the context menu. button1 events are ignored/refused; the signal handler returns FALSE to let the event go to the GtkButton as usual. Have you tried container.emit() instead of propagate_event? I think there's a good chance of it working. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] feature request: binding for gtk_propagate_event?
Have you tried container.emit() instead of propagate_event? I think
there's a good chance of it working.
Thanks, that seems to help. The right-clicks now drop through to the
underlying panel and manage to bring up the menu (and make it go away again).
I haven't figured out how to send button2 through (to invoke the drag-applet
stuff), but I figure I'll probably have to look more deeply into gnome-panel
to figure out what events it wants to receive that the GtkButton is
consuming.
I still wish I knew why this stopped working in Gnome2. I'm pretty sure it
was easier to use back in Gnome1.
For reference, here's the pair of helper functions I ended up using. Just use
MyButton() whereever you'd use gtk.Button(), and mouse2/3 press/release
events will be sent up to the Button's container:
def button_hack_helper(widget, event, updown):
if event.button != 1:
if updown == press:
widget.parent.emit(button_press_event, event)
else:
widget.parent.emit(button_release_event, event)
return gtk.TRUE
return gtk.FALSE
def MyButton():
b = gtk.Button()
b.connect('button_press_event', button_hack_helper, press)
b.connect('button_release_event', button_hack_helper, release)
return b
thanks for the help,
-Brian
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] feature request: binding for gtk_propagate_event?
Howdy all.. I've been trying to rewrite my python/gnome1 -based applets in python/gnome2 (somewhat forced into it because of the recent debian/unstable gnome2 switch). One of the more significant changes in gtk2/gnome2 that shows up in panel applets is that right-clicks on top of GtkButtons no longer result in the applet's menu appearing. I don't know if this is because GtkButtons consume the button2 and button3 events instead of passing them up to their containers (they do, but from what I can tell they did in gtk1.2 as well) or because the new bonobo-based libpanel-applet system does something different than the old applet-widget scheme (it does, but I don't know if it is not implementing an old workaround or if something else changed). The net result is that, in the applets I write that contain buttons, it is difficult to get to the applet's context menu (to configure or remove the applet). If the applet is all button, it is impossible. Several of standard Gnome applets (in gnome-applets-2.0.3), drivemount and mini-commander in particular, have a hack to work around this. The hack adds a signal handler to the GtkButton which catches button2/button3 and uses gtk_propagate_event() to send the event off to the applet as a whole, which responds by putting up the context menu. button1 events are ignored/refused; the signal handler returns FALSE to let the event go to the GtkButton as usual. In lieu of seeing GtkButtons changed to let button2/button3 events get passed along to their containers, I wanted to implement this same hack in my python applets. But gtk_propagate_event() is missing from the python binding, as it is listed in an %ignore clause in the gtk.override file. Any idea why there is no binding for this function? Or how hard it would be to add one? If there's a better workaround for this problem I'd love to hear it, but I suspect a real fix would involve changes to gtk that aren't going to happen any time soon. thanks, -Brian ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
