Am 15.11.2011 22:44, schrieb Tristan Van Berkom: > I think that it's obvious the mechanism is needed, but I dont think that we > should clear bindings based on sensitivity state, in other words I would much > rather that sensitivity always be the last thing which is evaluated based > on other real states (it doesnt seem to make sense that we drive a 'real' > project state based on the 'virtual' sensitivity state, and I fear with the > complexity of Glade that that will bite us later on). > > So, for the scenario you described above, functionally speaking I > think this needs > to happen: > > o Button editor sets the edit mode and does glade_command_push_group() > o Button editor does it's normal command group routines > o Button editor invalidates the "label" property (note: this > invalidation does not exist) > o Invalidating the "label" property causes bindings to that label to > become invalid, in > fact anything which "refers to that property" is invalid, today > this can only be a binding > of another property. > o A widget has a property which was bound to the "label" > property which was invalidated, > as a consequence of that action, it's binding to the said > label is undoably cleared > o GladeWidgetAdaptor->evaluate_sensitivity ( use_command = TRUE > ) is called on > that target property's widget to re-evaluate sensitivity > states after having changed > the binding state > o All widgets with any binding to the invalidated label finish > adjusting themselves to the > invalidation > o Button editor calls GladeWidgetAdaptor->evaluate_sensitivity ( > use_command = TRUE ) > on itself to evaluate the sensitivity after having changed it's > own "edit mode" > o Finally glade_command_pop_group() is hit > > The "invalidation" above might be a signal from the source > GladeProperty which has > a strict meaning, or possibly just a function > glade_command_property_invalidate() > which loops over all the targets, unsets them and resolves the > sensitivity of the > target widget.
I am not sure how the additional "invalidation" command you envision would conceptually differ from glade_command_set_sensitive (sensitive = FALSE). While I understand your intention, the fact that the property sensitivity *does* affect the binding state still remains in your proposed design; it is just indirected by the "invalidate" command. Also, the "invalidation" logic in the Editor would inevitably duplicate the logic in GladeWidgetAdaptor->evaluate_property_flags() (or ->evaluate_sensitivity(), we we're going to call it), meaning that changes to that logic alway requires modifications to two places (error-prone). In short, I think this needlessly complicates things without benefit. For reference, this is how the process works currently in the "command-set-sensitive" branch: 1. The Editor does glade_command_group_push() and does what it has always done. 2. Editor calls "GladeWidgetAdaptor->adjust_property_flags (use_command = TRUE)". That function's implementation uses glade_command_set_property_sensitive(), which checks whether any bindings become invalidated by the sensitivity change and, in turn, calls "glade_command_bind_property (binding_target, NULL)" as needed (grouped with the original sensitivity-setting command). 3. Editor calls glade_command_pop_group(). On loading a widget, ->adjust_property_flags() with use_command=FALSE is called. Regards, Denis _______________________________________________ Glade-devel maillist - Glade-devel@lists.ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel
