Re: bonobo_ui_handler_menu_set_toggle_state

[Darin Adler <darin eazel com>]

John Sullivan <sullivan@eazel.com> writes:

>> Currently it behaves as if the user had selected the menu item, but this
>> seems like it's the wrong choice. How can a caller set the state of the
>> checkbox without actually causing code to run? The same issue exists for the
>> radio button items.

Nat Friedman at nat@helixcode.com wrote:

> It's done like that because these are the semantics people expect;
> this is how Gtk+ operates.  The caller just has to be smart enough to
> know when he's initiated the state change himself.

If we really want this to match Gtk+, then perhaps we want the equivalent of
gtk_signal_block/unblock so handlers don't have to be removed and re-added
in this case.

> This is gross.  You're right; let's change the behavior so that it
> doesn't emit the signal.  Please add a note to this effect at the head
> of the method, though, so that people who expect the Gtk behavior
> don't get confused.

I'm not sure that's a good idea. This could be trouble-prone because the
caller is making that decision for all the other handlers of the
toggle_state "signal" (I guess it's not really a signal in this case). The
caller might know that one particular handler shouldn't be called because
"it" is part of the same code as that handler, but it's hard for it to make
any decisions for all other handlers that might be attached.

I like the Gtk design where an additional handler can be attached and is
guaranteed called at the right times. The caller can't forget to emit the
signal.

As you said, the same issue comes up in Gtk, and the approach there is that
the signal is emitted. But a common solution in Gtk is not available, since
you can only remove and re-add the callback function, without the
flexibility to block/unblock that signal handlers give.

    -- Darin