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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]