Re: Signals with default handlers

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

console_message seems to be the kind of signal that stops calling signal
handlers as soon as a called signal handler returns true. See the
description of g_signal_accumulator_true_handled.

When you connect your signal handler with
  m_web_view.signal_console_message().connect(sigc::mem_fun(this,
  &MyWindow::on_console_message));
it will be called after the default signal handler, but only if the
default signal handler returns false.
This behavior can be changed by setting the optional argument 'after' in
connect() to false:
  m_web_view.signal_console_message().connect(sigc::mem_fun(this,
  &MyWindow::on_console_message), false);
Then your signal handler will be called first. If it returns false, the
default signal handler will be called. If your signal handler returns
true, the default signal handler is not called.

ons 2011-06-01 klockan 13:28 +1200 skrev Gavin Lambert:
> I've been writing a program which uses webkitmm (and incidentally, if anyone
> is interested, I have some local updates to webkitmm to bring it up to
> support WebKit 1.4.0 -- though I haven't mm-encapsulated the JS/DOM/libsoup
> types).
> 
> 
> I'm getting some undesirable behaviour from a signal which has a default
> handler (virtual method defined in the underlying GTK+ class) --
> specifically, it appears to be ignoring attempts to connect a signal
> handler, and invoking the original GTK+ handler instead of my own.  Some
> relevant bits of code:
> 
> webkitmm source definition:
>   _WRAP_SIGNAL(bool console_message(const std::string& message, guint line,
> const std::string& source_id), "console-message")
> 
> Webkit/GTK signal definition:
>     webkit_web_view_signals[CONSOLE_MESSAGE] =
> g_signal_new("console-message",
>             G_TYPE_FROM_CLASS(webViewClass),
>             (GSignalFlags)G_SIGNAL_RUN_LAST,
>             G_STRUCT_OFFSET(WebKitWebViewClass, console_message),
>             g_signal_accumulator_true_handled,
>             NULL,
>             webkit_marshal_BOOLEAN__STRING_INT_STRING,
>             G_TYPE_BOOLEAN, 3,
>             G_TYPE_STRING, G_TYPE_INT, G_TYPE_STRING);
> 
> My attempt to attach signal handler:
>   m_web_view.signal_console_message().connect(sigc::mem_fun(this,
> &MyWindow::on_console_message));
> 
> My handler is never called; the default handler defined inside WebKit/GTK is
> called instead.
> 
> If I instead derive a subclass from WebView and override the virtual
> on_console_message function in that, then it gets called as expected.  (And
> if that calls the base class implementation, then it does both, as
> expected.)
> 
> So: why aren't "traditional" signal handlers getting called for this signal?
> Is this a bug or have I set something up incorrectly?
> 
> (Incidentally, signals wrapped using no_default_handler seem to correctly
> call their connected signal handler.)
> 
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list