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.
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.
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.
Cheers,
-Tristan
>
> 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
