Re: Update of GtkRadioMenuItems wihtout emitting any signal

["Mark R. Rubin" <markrubn pacbell net>]

Paul Davis <pbd Op Net> writes:

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

o 84 hits.  I'll read them.  Thanks.


> >    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.

o No problem.  Glad I'm not (totally) crazy.

o This is obviously one of the workable solutions.  The two
  relatively minor things I don't like about it are:

    1) object->state() is an additional requirement on the Model
       object's public interface.  Conceptually, what business does a
       View widget have knowing about the Model?  It should just be
       told what to display.

    2) Potential mismatch between Model object's internal state and
       View widget's represention of same.  Example: Model keeps
       double values, GtkAdjustment uses gfloats.  Or: Model keeps
       HTML/RTF/internationalized text, GtkText uses GtkText(??), some
       HTML widget uses HTML, so Model has to export multiple types of
       state (or maybe multiple overloads of operator!=()).


> >>        handle_widget_state_change (void *src) {
> >>              if (src == this) {
> >>                  /* ignore */
> >>                  return;
> >>              }
> >>              ....
> >>       }
> >> 
> ...
> >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.

o I also use gtk++(gtkmm) and libsigc++.  I think some of the
  nomenclature confusion here is because we're all translating back
  and forth between C/GTK and C++/GTK--.

o In C++ terms, my question was really "is the above
  handle_widget_state_change() a method of the object/Model class, or
  of the widget/View/Controller class"?

o In any case, I'm going to switch to the nomenclature you're using
  below.


> 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.

o Is "object" the Controller, or the Model?

o Bigger question: Do you use libsigc++ signals for *all* your MVC
  communication (both Controller-to-Model and Model-to-View)?

o I don't.  I use it for Controller-to-Model:

    Model::Model()
    :	_state1(false)
    {
         _togglebutton1
        .toggled
        .connect(bind<Gtk::ToggleButton*>(slot(*this,
&Model::button1_toggled),
                                                &_togglebutton1)) ;
    }

    Model::button1_toggled(
    const Gtk::ToggleButton  *togglebutton)
    {
        _state1 = togglebutton->get_active() ;
    }

o But for Model-to-View I just directly call the gtkmm methods:

    Model::some_method()
    {
        _state1 = some_computation() ;
        _togglebutton1.set_active(_state1) ;
    }
  
o I don't write my own methods for Views and Controllers -- they're
  just gtkmm widgets, used as-is.  I don't derive from them and
  extend/override (except for Gtk::DrawingArea).

o So my Model objects never emit signals (they just receive them) and
  my View/Controller objects never receive signals (just emit).  If
  yours go "both ways" it would explain my confusion over your
  (otherwise clear) descriptions.

o I'm going to table further questions pending an understanding of
  this, and a review of the list archives and the Gang Of Four book.


--
MARK
markrubn pacbell net