Havoc Pennington <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list