Subject: Re: [linux-audio-dev] Re: MVC
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Sun May 11 2003 - 00:57:31 EEST
>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
>
>
This archive was generated by hypermail 2b28 : Sun May 11 2003 - 01:05:54 EEST