Re: GtkBinding: this seems a hack to me

On Fri, 2006-07-07 at 12:45 +0200, Mardy wrote:
> Hi all!
>   I have registered in a widget of mine a signal of type action to be
> activated by a key binding. I declared a gboolean return type for my
> signal, but now I realize this was a mistake: in gtkbinding.c the
> boolean return value for signals is handled in a special way, which
> causes the gtk_binding_entry_activate not to return TRUE even if the
> signal has been handled correctly.
> This is the piece of code (gtkbinding.c):
> ==================
> if (query.return_type == G_TYPE_BOOLEAN)
>     g_value_init (&return_val, G_TYPE_BOOLEAN);
> g_signal_emitv (params, signal_id, 0, &return_val);
> if (query.return_type == G_TYPE_BOOLEAN)
> {
>   if (g_value_get_boolean (&return_val))
>     handled = TRUE;
>   g_value_unset (&return_val);
> }
> else
>     handled = TRUE;
> ==================
> I guess this behaviour is needed by some other widgets, but it seems
> quite wrong to me: the "handled" variable should be set to TRUE no
> matter what the signal returns, since my signal's boolean return value
> has nothing to do with this.
> By now, I'll workaround this behaviour by setting my signal handler to
> return an integer value rather than a boolean, so that this won't be
> misinterpretated by gtkbinding.c; but please consider this issue,
> whether this special handling is really needed.

Similar to how event handling works, if a signal bound to a key binding
returns TRUE, it means "yes, I handled it", if it returns FALSE,
it means "No, I didn't handle it". If the signal doesn't have a a
return value, then we assume that it always handles the key binding.

This wasn't done for fun, or to cause you problems: the point here is to
allow key bindings that take effect only when a widget is in a
particular state. You will find examples of its usage in GTK+ if you
look through the code.

I don't consider it a hack at all; I think it's a pretty clean extension
of principles that apply elsewhere in GTK+, but even if it was a hack,
it's not changeable at this point.

If you have a signal that has a return value with a different meaning,
it is not suitable for binding to a key binding. You'll have to add
another signal to act as the key binding.


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