10 May
2003
10 May
'03
6:04 p.m.
So if the menu radio button changes we want to update
the toggle button
and vice versa. Lets say the user changes the menu radio button, the
loop would occur when in the radio button toggle handler we set the
state of the toolbar toggle button, which then triggers the toolbar
toggle button, which sets the menu toggle button, etc.
The menu radio button toggle handler would look something like this in C
(we are passing the toolbar toggle button to the signal handler using
the user defined pointer):
void
menu_radio_item_toggled_callback (GtkWidget *radio_item,
gpointer user_data)
{
GtkWidget *toolbar_btn = GTK_WIDGET (user_data);
gboolean active;
/* get state of radio menu item */
active = gtk_check_menu_item_get_active (GTK_CHECK_MENU_ITEM (radio_item));
/* block the toolbar button signal handler to prevent loop */
g_signal_handlers_block_by_func (toolbar_btn,
toolbar_btn_toggled_callback,
radio_item);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toolbar_btn),
active);
/* unblock */
g_signal_handlers_unblock_by_func (toolbar_btn,
toolbar_btn_toggled_callback,
radio_item);
}
its close, but still not quite what i was thinking of. you want to be
able to change the model, which will then change the appearance of the
view.
take a simple example: someone is using a MIDI control surface, and
they press a button that causes a track in ardour to become
rec-enabled. we want the GUI to show that, just as if they had pressed
it in the GUI. when you change the appearance of the view to match the
model, it can be hard to do this in a way that doesn't make it appear
to the GUI toolkit that the user has in fact pressed the GUI
button. this then causes an entire cycle of state change code in the
model, since presumably, when the GUI button is pressed, something is
supposed to happen in the model.
consequently, with GTK+ 1.2 (at least), you end up having to have lots
of checks to see if (a) the new model state is the same as the
existing model state (and do nothing to the model if so) and (b) the new model
state matches the current view state already (and do nothing to the
view if so).
it would be much nicer to be able to have methods for setting the view
state that are explicitly acknowledged as coming "from" the
program, and are not related to keyboard/mouse events driven by the
toolkit. i don't know of any toolkit that does this (which is not to
say they don't exist).
--p
In this example we blocked by callback function and data (the data is
significant and must match the data when the signal is connected, the
radio button in the case of the toolbar toggle button callback). You can
also save the signal handler ID and use it to block the handler.
--p
I think thats what you were talking about. I wouldn't be surprised if I
rambled on about something completely different though. Cheers.
Josh Green