Am 18.11.2011 19:49, schrieb Tristan Van Berkom: > On Fri, Nov 18, 2011 at 2:24 AM, Denis Washington<den...@online.de> wrote: >> 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 > > And enter the confusion: > > a.) Bindings use this virtual state of 'sensitivity' to clear themselves > b.) Anything else... like activatable properties, looks at the code you > wrote and decides that it's also a good idea to clear itself when it > something goes insensitive > c.) Code competes for real states because of insignificant > sensitivity changes > > Yes, it is important that when one editor sets a property insensitive, > the binding > updates/clears itself, however it is also important that that clearing > is not simply > *because* of the sensitivity state.
OK, I think I know where you're getting at now. You want to ensure that the binding removal only happens if a property is made sensitive because it is invalidated by an Editor, not because of any other random kinds of property sensitivity changes. Seen this way, a separate "invalidation" command is surely a superior design. > > At any rate, if you were to drive the project states from the sensitivity > state, > you would still need to find a way to do it undoably while the sensitivity is > set as a command. > > i.e. it's important that: > > a.) Editor sets activatable stuff that makes a property insensitive > b.) Property undoably goes insensitive > c.) Binding is undoably unset > > a, b and c have to happen as part of the same command group (so you > cant very well listen to a sensitivity changed signal and clear the > binding state). > >> 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). > > Right, so in this specific step we have code that explicitly writes out that > if > you set a property insensitive... *only* bindings are effected, which singles > out bindings as some kind of a special case feature. > > This is where a generalized "clear property" with a general meaning would > be better. Actually, I agree with this now. A separate notion of invalidation is much clearer and less fragile. Given that, we might even be able to omit glade_command_set_property_sensitive() and call GladeWidgetAdaptor->evaluate_sensitivity() from the invalidation command instead. > Historically you need to know that all the worst code ends up in > glade-command.c > because we are too lazy to do things properly, then we add adaptor methods to > do things more generically and pull hard-code out of glade-command.c... I'm > just > trying to avoid that. So you're thinking of something like GladeWidgetAdaptor->invalidate()? How would that be better than simply having glade_command_invalidate_property()? I cannot think of any way thank specific widget types would need different implementations of this. Regards, Denis _______________________________________________ Glade-devel maillist - Glade-devel@lists.ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel
