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.)
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
