Re: Update of GtkRadioMenuItems wihtout emitting any signal

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

Havoc Pennington <hp redhat com> writes:

> It depends on the situation. Some approaches are:
> 
>  - gtk_signal_handler_block (g_signal_handlers_block, and by_func variants)
>  - don't do anything in the callback if the value hasn't changed:
>     if (current_state == gtk_toggle_button_get_active (toggle))
>       return;
>  - fill in the default state of controls before you connect the 
>    callbacks to them
> 
> You can also use a global flag or a flag specific to a class/object, 
> but I don't like that approach much personally.

o I don't like it much, either.  (That's why I wrote "it's [still]
  pretty ugly".)

o Thanks for weighing in on this.  I didn't know about
  gtk_signal_handler_block(), etc., and will look into them.
  Unfortunately, a quick check seems to say they're not exposed in
  GTK-- (gtkmm), which is what I mostly use.

o I need to test the performance of various solutions.  Amongst:

    1) Set a flag, change the widget, let the signal happen, test the
       flag.

    2) Check current state in callback, do nothing if unchanged.
       (Requires maintaining a separate copy of the widget state --
       isn't the XXX_get_YYY() or the adjustment value already changed
       by the time you're in the callback?)

    3) gtk_signal_handler_block(), change the widget,
       gtk_signal_handler_unblock()

    4) disconnect the signal, change the widget, re-connect the signal

  my guess is that #1 or #2 are still the most efficient.  I do have
  cases where performance is important.  Example: CAD program where
  user can set the current object's position by inputting x,y in
  spinbuttons, but can also drag the object around in its drawing area
  while the spinbuttons display x,y.


> Most signals indicate that the state of an object has changed, not
> that it has changed due to some specific cause (e.g. user input). 
> This is the right thing IMO for reasons of conceptual cleanliness;
> there would be lots of subtle tricky bugs otherwise. In any case it's
> too late to change this aspect of GTK.

o I agree on conceptual cleanliness and that it's "too late" (would
  break huge number of programs).  I do wonder what it would take to
  add a widget specific (and/or global-affect-all-widgets) command to
  optionally change the behavior to "emit signal only on user input".
  Default stays the way it is now; no programs break.  Someday I'll
  look through the source and see.

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


--
MARK
markrubn pacbell net