Re: Update of GtkRadioMenuItems wihtout emitting any signal

[Paul Davis <pbd Op Net>]

>o I also have trouble believing that Ignacio Nodal and myself are the
>  only ones who've ever been bitten by this.  Screen real estate is
>  always precious, and re-using a widget for input and output always
>  helps (and is easier on the user than "click this togglebutton to
>  change from "input values" to "display values" mode).

you're not the only ones; i've discussed this issue several times on
this list in the past. however, if you're really doing
Model-View-Controller style programming, which is highly desirable and
it sounds as if you are, then Havoc's suggestion of:

   handle_widget_state_change () {
      if (widget->representation_of_object_state() != object->state())
	    widget->set_state (object->state());
  }

is the *only* correct route to take here.

in my C++ code, i tend to use a void * (aka gpointer) as an extra arg
to all functions that change the state of my objects ("models"), an
arg i call "src". when the objects emit signals as a result of the
change, they include the "src" argument. as a result, widgets ("views"
and/or "controllers") can do things like:

       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.

however ... despite the fact that i found this to be a rather elegant
solution, i think that there are hardly any places in my code where i
make this check, and that number is going down all the time. the
explicit comparison of widget state and object state now dominates my
code, and it generally feels "right".

your suggestion for "emit only on user input" will break proper MVC
programming as soon as there are non-X-based methods of changing
object or widget state. most of my programs accept MIDI input, for
example, that can be used to change object states, and i expect my
widgets to follow those changes. unless you provide a way to say
"change this GtkAdjustment as if i were a user" and "change this
GtkAdjustment as if i were not a user", which is deeply cumbersome,
somewhere down the line, there has to be a call to "change this
GtkAdjustment", and that *must* emit a signal that can be
caught. anything less will, as Havoc intimated, and as i now
emphasize, break a good MVC design in many subtle and not so subtle
ways.

--p