[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: event callback order



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]