[Glade-devel] Property Binding: Fixing the big blocker

[Denis Washington]

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