[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: event callback order
- From: "muppet" <scott asofyet org>
- To: gtk-perl-list gnome org
- Subject: Re: event callback order
- Date: Mon, 12 Sep 2005 14:41:00 -0400 (EDT)
James Muir said:
> Based on this output I'd say that the driver program is handling the
> event before the object that it instantiates, but I'd really like the
> MapItem to have first dibs. Any insights and help appreciated.
That's the way that run-last signals work. GnomeCanvasItem::event happens to
be a run-last signal:
$ perl -MData::Dumper -MGnome2::Canvas -e 'print "".Glib::Type->list_signals
('Gnome2::Canvas::Item')->{signal_flags}."\n"'
[ run-last ]
This is part of how GObject signal emission works; it's described in fairly
useful detail in the tutorial portion of the GObject manual:
http://developer.gnome.org/doc/API/2.0/gobject/signal.html#signal-emission
(That used to be Matthieu Lacage's GObject tutorial, which was merged this
year into the GObject docs.)
There's a more terse description in the reference portion of the manual :
http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html
Events wind up being run-last signals because they use a return value (the "is
the event handled?" flag).
On the other hand, if you're creating your own signals, you get to choose.
Here's a primitive illustration of how those things work:
package Thing;
use strict;
use Glib qw(:constants);
use Glib::Object::Subclass
Glib::Object::,
signals => {
poked => {
flags => 'run-first',
class_closure => sub { print "poked: class closure\n" },
},
prodded => {
flags => 'run-last',
class_closure => sub { print "prodded: class closure\n" },
},
};
sub poke { $_[0]->signal_emit ('poked') }
sub prod { $_[0]->signal_emit ('prodded') }
package main;
my $thing = new Thing;
$thing->signal_connect (poked => sub { print "poked: user callback 1\n"; });
$thing->signal_connect (poked => sub { print "poked: user callback 2\n"; });
$thing->signal_connect (prodded => sub { print "prodded: user callback 1\n";
});
$thing->signal_connect (prodded => sub { print "prodded: user callback 2\n";
});
$thing->poke();
$thing->prod();
The output is:
$ perl signal.pl
poked: class closure
poked: user callback 1
poked: user callback 2
prodded: user callback 1
prodded: user callback 2
prodded: class closure
User callbacks are executed in the order they were connected, and the signal
flags determine when the class closure runs.
--
muppet <scott at asofyet dot org>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]