Re: GtkRadioMenuItem set active problem

[Owen Taylor <otaylor redhat com>]

Jeff Franks <jcf tpg com au> writes:

> Owen Taylor wrote:
> 
> >Jeff Franks <jcf tpg com au> writes:
> >
> >>Hi,
> >>
> >>I've come across a problem with GtkRadioMenuItem. The only way to set
> >>the active item in a group is to call 'gtk_check_menu_item_set_active'
> >>which also emits an 'activate' signal. This is ok when a program is up
> >>and running but when you are initializing a program, emitting an
> >>'activate' signal can be undesireable. When adding a group of
> >>radiomenuitems all you really want to do is let GtkRadioMenuItem know
> >>which way to draw its indicator. Since
> >>'gtk_radio_menu_item_draw_indicator' checks 'GtkCheckMenuItem::active'
> >>before drawing the indicator wouldn't it be reasonable to let
> >>GtkRadioMenuItem have a way to set/unset this flag without emitting an
> >>'activate signal. The best place for this might be as extra parameter
> >>in the 'gtk_radio_menu_item_new' functions.
> >>
> >
> >I don't see this is being any different from a toggle button,
> >where gtk_toggle_button_set_active() emits ::toggled.
> >
> >Generally, in response to any sort of change notification, instead of
> >assuming that a change happened, you should get the current state and
> >compare it against your internal state.
> >
> I was testing GtkRadioMenuItem. While initializiing the main window I
> was adding a submenu of 4 radiomenutiems. I wanted the previously
> saved option to be restored when the menu was displayed. As I added
> the menuitems if the menutitem being added matched the previously
> saved item I set it to active by calling
> 'gtk_check_menu_item_set_active'. This emitted an activate signal
> during program initialization which tried to activate partially
> initialized code. All I wanted during initialization was to let the
> radiomenuitems know which one should be drawn active. You can't check
> the internal state here because it is the default GtkRadioMenuItem
> state. Remember the program is being initialized and is not yet up and
> running. I accomplished what I wanted to by directly setting the
> GtkCheckMenuItem::active flag for each item and everthing works ok.

This is illegal. You can't do this.

And basically for the same reasons, it doesn't make sense to have
an API to "silently" set the state of an item. There might be
third parties that are monitoring the state of an item via
signals.

> Since radiomenuitems operate as a group isn't it reasonable, during
> initialization of a group and before the group is visible, that you
> can somehow tell the group which item should be drawn in the active
> state without having an activate signal emitted.

I still don't get how this is different than any other control
in GTK+ where you are both setting and connecting to change
notification on a widget. 

There are a number of ways of dealing with notifiction of
changes you make yourself.

 - Not connect your signals until you are done with initialization

 - Set a "global" flag indicating that you are making changes,
   and ignore changes when that flag is set

 - Use the "block" feature of the GTK+ signal system to block
   your change notification handlers.

 - Change your internal state before you change the state of the
   widget, then, when you get notification, compare the new
   state of the widget with your internal state.

The last is frequently the cleanest route, but is not the only
one. All of these seem to be applicable your situation, except
maybe using gtk_signal_handle_block(), since that may not
have an equivalent in libsigc++.
 
> I guess this situation arose because I was writng in C++ using
> libsig++ and had directly linked the activation to a response using
> 'bind' during the initialization.

Frequently, it is necessary to first create your user interface,
then connect to signals.

                                        Owen