Re: Update of GtkRadioMenuItems wihtout emitting any signal

[Paul Davis <pbd Op Net>]

>  searched the archives for this, but never found the right
>  keywords.  Could you provide some "Subject:" lines?   Searching for

try "MVC" in the body, since i usually use that acronym when
discussing this.

>  a little differently.  If his "current_state" is your
>  "object->state()" (which makes more sense than my interpretation of
>  "widget->previous_state()"), and if "handle_widget_state_change()"
>  is a GTK signal-handler/callback, I would think it should be:
>
>    handle_widget_state_change () {
>        if (widget->representation_of_object_state() != object->state())
>            object->set_state (widget->state());
>    }

yes, thats right. i wasn't being careful enough as i tuped that
in. sorry about that.

>>        handle_widget_state_change (void *src) {
>>              if (src == this) {
>>                  /* ignore */
>>                  return;
>>              }
>>              ....
>>       }
>> 
>> this lets a widget set the state of its underlying object (when acting
>> as a controller), supplying "itself" as the src pointer, and thus
>> ignore any notifications from the object when they are sent following
>> the object's state change.
>
>o Is the "this" in the above code fragment the object (Model) or the
>  widget (View/Controller)?  If object/Model, I don't understand
>  because mine don't emit signals (widgets/Controllers emit signals;
>  objects/Models do things like gtk_toggle_button_set_active()).  If
>  "this" is the widget/Controller, when "src==this" is exactly when
>  the action should take place.

sorry. i work in C++ and i use libsigc++ which offers me a superb
system for writing MVC programs. the "this" i used above refers to the
thing "on whose behalf" a member function is beind called. its an
"implicit" argument in all C++ member functions.my objects all attempt
to remain anonymous and ignorant of who has registered an interest in
their state changes, which libsigc++ makes *phenomenally* easy to
do. so, suppose we have a true MVC system that includes:

    Controller::do_something_to_model (Model *model)
    {
       model->set_state (foo, this);
    }

this causes "object" to emits its "StateChanged" signal. Now, suppose
that we have a view hooked up to the signal, with a handler:

    View::handle_model_state_change (void *src)
    {
       if (src == this) {
	   /* we initiated the state change in the model,
	      so presumably our visual appearance is up-
	      to-date. relax.
	    */
	    return;
       }

       ... something else changed the model's state ...
       ... make our appearance reflect the model's state ...
    }

now, as you have noted, its common to use a single widget as both a
"controller" and a "view". in that case, you'd have 

      	     
    ControllerView::do_something_to_model (Model *model)
    {
        model->set_state (foo, this);
	... change visual appearance if appropriate ...
    }

this would presumably be called because of some GUI event (e.g. a
button click). We will still have:

    ControllerView::handle_model_state_change (void *src)
    {
    }

but this time, we will find out that the "src" of the change is
ourselves. Presumably, our appearance is already correct (we responded
to that in do_something_to_model(), so we can just return.

Does this make this style any clearer? As I say, I've found that I've
managed to avoid this by comparing model state to view state, but its
still useful occasionally. There are other ways of tackling what 
ControllerView::do_something_to_model() does - its worth reading up on
MVC programming and/or "Design Patterns" to get a handle on some of them.

--p