On Tue, Nov 15, 2011 at 4:08 PM, Denis Washington <den...@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
_______________________________________________
Glade-devel maillist - Glade-devel@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel
