Re: bonobo_ui_handler_menu_set_toggle_state
- From: James Antill <james-gnome-components and org>
- To: Nat Friedman <nat helixcode com>
- Cc: gnome-components-list <gnome-components-list gnome org>
- Subject: Re: bonobo_ui_handler_menu_set_toggle_state
- Date: 21 Mar 2000 11:13:25 -0500
Nat Friedman <nat@helixcode.com> writes:
> John Sullivan <sullivan@eazel.com> writes:
>
> > Ettore, thanks for youre reply.
> >
> > I have at least for now used a workaround for this problem. Before calling
> > set_toggle_state I save the callback function and then set the callback
> > function to NULL. Then I call set_toggle_state. Then I restore the callback
> > function.
> >
> > This works for my purposes, but feels like a hack. However, I will defer to
> > the Bonobo maintainers the question of whether or not set_toggle_state
> > should trigger the callback function.
>
> 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.
But what happens if you are triggering other GUI elements based upon
the radio buttons (I can imagine it would happen more often with check
boxes, but I'm guessing it will happen with radio buttons as well).
This seems like to use a bonobo component you'd need intimate
knowlege of what it did and how.
I'm guessing it's not possible to pass a flag saying this UI change
is "interactive" while that one isn't ?
--
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]