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

[Tristan Van Berkom]

On Tue, Nov 15, 2011 at 4:08 PM, Denis Washington <denisw at online.de> wrote:
> Am 15.11.2011 20:59, schrieb Tristan Van Berkom:
>>
>> Denis,
>>     Thanks for taking time to send this mail, it's good that we archive
>> this plan which we drafted in our irc session for future reference.
>>
>> Because this GBinding thing is turning out to be complex, what I really
>> want (and I think you might have missed that, sorry if I wasn't clear) is
>> an explanation of how recording sensitivity in the undo/redo stack
>> solves the GBinding branch problems.
>
> Oh, I missed that indeed. My bad.
>
> The problem is that without recording sensitivity changes, we cannot cleanly
> detect property bindings that become invalid due to these changes and must
> be removed (or, at least, warned about).
>
> For instance, imagine that you bound some widget's property to the "label"
> property of a button (that is, "label" is the source). Now you change the
> type of the button's content from "Label" to "Custom Widget". Clearly, the
> binding makes no sense anymore - there is no label anymore to get a source
> value from. So setting the "label" property insensitive should have the side
> effect of removing the binding, undoably (that is, as a command). But there
> is no sensible place in the code to do this at the moment.
>
> If, on the other hand, there were a glade_command_set_property_sensitive(),
> that function could check for bindings that are going to become invalid and
> invoke further undoable commands to remove them. This would ensure that
> setting a property insensitive and removing all affected bindings is always
> a single, atomic, undoable operation.

Thanks that's what I wanted to start getting at.

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.

Essentially I think it's just a simple nuance from what you have planned, only
that the sensitivity should be based on real data and not the other way around.

Also, you will find a hand full of use cases where properties go
sensitive/insensitive
without the help of a custom editor, perhaps we need to "resolve sensitivity" on
any widget any time that any of it's properties are set by a GladeEditorProperty
(i.e. once in glade_editor_property_commit())... not sure if that
would slow things down
very much when editing string properties...

Cheers,
       -Tristan