[Glade-devel] Property Binding: Fixing the big blocker
- From: denisw at online.de (Denis Washington)
- Subject: [Glade-devel] Property Binding: Fixing the big blocker
- Date: Fri, 18 Nov 2011 08:24:27 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]