Property Binding: Fixing the big blocker

[Denis Washington]

Hi,

After an unfortunate longer period of inactivity, I am happy to tell you
that I started to work on bringing GObject property binding support to
Glade again where I left off last summer after GSoC [1]. (By the way, I
passed final evaluation! Thanks to everyone involved! Thank for
mentoring me, Juan! :) This message is intended as a quick update what I
am doing now.

In my last message to this list [2], I mentioned that the current Glade
codebase doesn't record changes to the sensitivity of properties (such
as, e.g., making the "label" property of a GtkButton insensitive when
that button is set to have a custom content widget) in its command
(undo/redo) system, and that this makes it impossible to cleanly
auto-remove property bindings that become invalid this way. Tristan
identified this problem as a blocker to the adoption of the property
binding branch [3] into master, so this is what I'm starting to tackle now.

For this purpose, I created a new branch named "command-set-sensitive"
to convert all relevant property sensitivity changes to undoable
commands. (I am not doing this in the "gbinding" branch directly to
allow for easier isolated reviewing and testing.) The branch introduces
the following (as loosely discussed with Tristan):

- A new command function, named glade_command_set_property_sensitive(),
which sets the sensitivity of a single property undoably. Being more of
a side effect, this command is always group with other commands (such as
switching the content type of a GtkButton) and should never stand on its
own.

- A new virtual function of GladeWidgetAdaptor,
glade_widget_adaptor_adjust_property_flags(), which can be overridden
for each type of widget to provide a property sensitivity policy. It
accepts a "use_command" boolean parameter which tells the function
whether to use the command system for sensititivity changes or call
glade_widget_property_set_sensitive() directly. (The latter is required
when the widget is first created, or when it is loaded from a file.)

- A port of a small portion of the GTK+ plugin to the new functions as
an example. (Currently, only the GtkEntry-related port is ported.)

I hope that this work enables me to fix the last remaining big blocker
bug before the property binding branch is ready for prime time. Any
feedback is very welcome! (@Tristan: Please review when you find the time!)

Regards,
Denis

[1] https://live.gnome.org/DenisWashington_GtkBuilder
[2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html
[3] http://git.gnome.org/browse/glade/log/?h=gbinding
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Denis Washington
Hi,
After an unfortunate longer period of inactivity, I am happy to tell you
that I started to work on bringing GObject property binding support to
Glade again where I left off last summer after GSoC [1]. (By the way, I
passed final evaluation! Thanks to everyone involved! Thank for
mentoring me, Juan! :) This message is intended as a quick update what I
am doing now.
In my last message to this list [2], I mentioned that the current Glade
codebase doesn't record changes to the sensitivity of properties (such
as, e.g., making the "label" property of a GtkButton insensitive when
that button is set to have a custom content widget) in its command
(undo/redo) system, and that this makes it impossible to cleanly
auto-remove property bindings that become invalid this way. Tristan
identified this problem as a blocker to the adoption of the property
binding branch [3] into master, so this is what I'm starting to tackle now.
For this purpose, I created a new branch named "command-set-sensitive"
to convert all relevant property sensitivity changes to undoable
commands. (I am not doing this in the "gbinding" branch directly to
allow for easier isolated reviewing and testing.) The branch introduces
- A new command function, named glade_command_set_property_sensitive(),
which sets the sensitivity of a single property undoably. Being more of
a side effect, this command is always group with other commands (such as
switching the content type of a GtkButton) and should never stand on its
own.
- A new virtual function of GladeWidgetAdaptor,
glade_widget_adaptor_adjust_property_flags(), which can be overridden
for each type of widget to provide a property sensitivity policy. It
accepts a "use_command" boolean parameter which tells the function
whether to use the command system for sensititivity changes or call
glade_widget_property_set_sensitive() directly. (The latter is required
when the widget is first created, or when it is loaded from a file.)
- A port of a small portion of the GTK+ plugin to the new functions as
an example. (Currently, only the GtkEntry-related port is ported.)
I hope that this work enables me to fix the last remaining big blocker
bug before the property binding branch is ready for prime time. Any

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.

In a nutshell, can you give us a status of the GBinding integration ?

I just want to have an idea of if this is really the last blocker, why is
it the last blocker and if not, what remains to be done.

Cheers,
-Tristan

Post by Denis Washington
Regards,
Denis
[1] https://live.gnome.org/DenisWashington_GtkBuilder
[2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html
[3] http://git.gnome.org/browse/glade/log/?h=gbinding
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Post by 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.

I hope this answers your question.

Regards,
Denis
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by Denis Washington

Post by 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-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Post by 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
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
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by 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
  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
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-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Post by Tristan Van Berkom

Post by 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
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

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.

OK, I think I know where you're getting at now. You want to ensure that
the binding removal only happens if a property is made sensitive because
it is invalidated by an Editor, not because of any other random kinds of
property sensitivity changes. Seen this way, a separate "invalidation"
command is surely a superior design.

Post by Tristan Van Berkom
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.
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
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.

Actually, I agree with this now. A separate notion of invalidation is
much clearer and less fragile. Given that, we might even be able to omit
glade_command_set_property_sensitive() and call
GladeWidgetAdaptor->evaluate_sensitivity() from the invalidation command
instead.

Post by Tristan Van Berkom
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.

So you're thinking of something like GladeWidgetAdaptor->invalidate()?
How would that be better than simply having
glade_command_invalidate_property()? I cannot think of any way thank
specific widget types would need different implementations of this.

Regards,
Denis
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Tristan Van Berkom]

Post by 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
  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

   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.

OK, I think I know where you're getting at now. You want to ensure that the
binding removal only happens if a property is made sensitive because it is
invalidated by an Editor, not because of any other random kinds of property
sensitivity changes. Seen this way, a separate "invalidation" command is
surely a superior design.

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.
  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
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.

Actually, I agree with this now. A separate notion of invalidation is much
clearer and less fragile. Given that, we might even be able to omit
glade_command_set_property_sensitive() and call
GladeWidgetAdaptor->evaluate_sensitivity() from the invalidation command
instead.

Yes that's kindof what I had in mind, ideally the source and target evaluate
the sensitivity using the adaptor method in as most cases as possible (hopefully
all cases).

The other detail about the 'clear property' or 'invalidate property' semantics
is not entirely clear to me, I suppose one approach would be to fire a signal
on a GladeProperty when it is supposed to be cleared.

For instance...

o the activatable editor goes ahead and clears
a property which is actually a binding source (somewhere inside
the command group which it declares)... possibly by calling
glade_property_clear (property, use_command = TRUE);

o Then the "clear" or "invalidate" signal is fired on the said GladeProperty
with a 'use-command' parameter as TRUE

o GladeProperty code would implicitly connect to the "invalidate" signal
on it's set 'source property', when the property is cleared then the source
property attribute can be unset undoably

o Some specific GladeWidgets will be allowed to connect to an "invalidate"
signal on a property of another GladeWidget, if ever more code is developed
which needs to do an action at property invalidation time, this can be done
by listening to this signal and without adding custom code to
glade-command.c

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.

So you're thinking of something like GladeWidgetAdaptor->invalidate()? How
would that be better than simply having glade_command_invalidate_property()?
I cannot think of any way thank specific widget types would need different
implementations of this.

No no, I was just trying to illustrate how particularly fragile the
"Controller"
element of Glade's MVC model is (or can potentially get, when trying to
handle things using a procedural approach from glade-command.c, which
is always the most obvious approach ... but has drawbacks).

And... thanks a lot for your patience with this.
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Post by Tristan Van Berkom

Post by Tristan Van Berkom
This is where a generalized "clear property" with a general meaning would
be better.

Actually, I agree with this now. A separate notion of invalidation is much
clearer and less fragile. Given that, we might even be able to omit
glade_command_set_property_sensitive() and call
GladeWidgetAdaptor->evaluate_sensitivity() from the invalidation command
instead.

Yes that's kindof what I had in mind, ideally the source and target evaluate
the sensitivity using the adaptor method in as most cases as possible (hopefully
all cases).

OK, great. So I guess good places would be:

- After widget creation / load
- Property editor post-commit

Post by Tristan Van Berkom
The other detail about the 'clear property' or 'invalidate property' semantics
is not entirely clear to me, I suppose one approach would be to fire a signal
on a GladeProperty when it is supposed to be cleared.
For instance...
o the activatable editor goes ahead and clears
a property which is actually a binding source (somewhere inside
the command group which it declares)... possibly by calling
glade_property_clear (property, use_command = TRUE);
o Then the "clear" or "invalidate" signal is fired on the said GladeProperty
with a 'use-command' parameter as TRUE
o GladeProperty code would implicitly connect to the "invalidate" signal
on it's set 'source property', when the property is cleared then the source
property attribute can be unset undoably
o Some specific GladeWidgets will be allowed to connect to an "invalidate"
signal on a property of another GladeWidget, if ever more code is developed
which needs to do an action at property invalidation time, this can be done
by listening to this signal and without adding custom code to
glade-command.c

This sounds like a sensible approach (although I would really call it
glade_property_invalidate(), as this makes the intention and the
difference to "resetting" a property clearer). I could go ahead and
implement this and see how it works out.

Post by Tristan Van Berkom

Post by Tristan Van Berkom
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.

So you're thinking of something like GladeWidgetAdaptor->invalidate()? How
would that be better than simply having glade_command_invalidate_property()?
I cannot think of any way thank specific widget types would need different
implementations of this.

No no, I was just trying to illustrate how particularly fragile the
"Controller"
element of Glade's MVC model is (or can potentially get, when trying to
handle things using a procedural approach from glade-command.c, which
is always the most obvious approach ... but has drawbacks).

Ah, ok.

Post by Tristan Van Berkom
And... thanks a lot for your patience with this.

No problem. :)

Regards,
Denis
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Post by Denis Washington

Post by Tristan Van Berkom
The other detail about the 'clear property' or 'invalidate property' semantics
is not entirely clear to me, I suppose one approach would be to fire a signal
on a GladeProperty when it is supposed to be cleared.
For instance...
o the activatable editor goes ahead and clears
a property which is actually a binding source (somewhere inside
the command group which it declares)... possibly by calling
glade_property_clear (property, use_command = TRUE);
o Then the "clear" or "invalidate" signal is fired on the said GladeProperty
with a 'use-command' parameter as TRUE
o GladeProperty code would implicitly connect to the "invalidate" signal
on it's set 'source property', when the property is cleared then the source
property attribute can be unset undoably
o Some specific GladeWidgets will be allowed to connect to an "invalidate"
signal on a property of another GladeWidget, if ever more code is developed
which needs to do an action at property invalidation time, this can be done
by listening to this signal and without adding custom code to
glade-command.c

This sounds like a sensible approach (although I would really call it
glade_property_invalidate(), as this makes the intention and the
difference to "resetting" a property clearer). I could go ahead and
implement this and see how it works out.

Hi, I wanted to say that I just pulled
glade_command_set_property_sensitive() out of the branch and just left
GladeWidgetAdaptor::evaluate_property_sensitivity() there. Consequently,
the branch is now named "evaluate-sensitivity".

I added a call to evaluate_property_sensitivity() to
glade_property_set_value_impl(), and for the case that I ported so far
(GtkEntry), this works perfectly.

As there is no need for it outside of the gbinding branch, I'll add
glade_property_invalidate() to that branch directly. I guess I'll also
rebase gbinding to the evaluate-property branch to make testing easier.

Regards,
Denis
_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Denis Washington]

Hi,

I have finally commited all code to fix the bug in the "gbinding"
property binding branch that I described earlier (see below). Now all
GladeEditor subclasses in plugins/gtk+/ call the newly introduced
glade_property_invalidate() function when a property is disabled, which
causes all properties bound to the disabled property to be unbound
automatically. This means that all situations where the user changes the
sensitivity of a property with the inspector are handled correctly now
from property binding standpoint.

If there are any other cases where glade_property_invalidate() needs to
be called, please let me know.

Regards,
Denis

Post by Denis Washington
Hi,
After an unfortunate longer period of inactivity, I am happy to tell you
that I started to work on bringing GObject property binding support to
Glade again where I left off last summer after GSoC [1]. (By the way, I
passed final evaluation! Thanks to everyone involved! Thank for
mentoring me, Juan! :) This message is intended as a quick update what I
am doing now.
In my last message to this list [2], I mentioned that the current Glade
codebase doesn't record changes to the sensitivity of properties (such
as, e.g., making the "label" property of a GtkButton insensitive when
that button is set to have a custom content widget) in its command
(undo/redo) system, and that this makes it impossible to cleanly
auto-remove property bindings that become invalid this way. Tristan
identified this problem as a blocker to the adoption of the property
binding branch [3] into master, so this is what I'm starting to tackle now.
For this purpose, I created a new branch named "command-set-sensitive"
to convert all relevant property sensitivity changes to undoable
commands. (I am not doing this in the "gbinding" branch directly to
allow for easier isolated reviewing and testing.) The branch introduces
- A new command function, named glade_command_set_property_sensitive(),
which sets the sensitivity of a single property undoably. Being more of
a side effect, this command is always group with other commands (such as
switching the content type of a GtkButton) and should never stand on its
own.
- A new virtual function of GladeWidgetAdaptor,
glade_widget_adaptor_adjust_property_flags(), which can be overridden
for each type of widget to provide a property sensitivity policy. It
accepts a "use_command" boolean parameter which tells the function
whether to use the command system for sensititivity changes or call
glade_widget_property_set_sensitive() directly. (The latter is required
when the widget is first created, or when it is loaded from a file.)
- A port of a small portion of the GTK+ plugin to the new functions as
an example. (Currently, only the GtkEntry-related port is ported.)
I hope that this work enables me to fix the last remaining big blocker
bug before the property binding branch is ready for prime time. Any
Regards,
Denis
[1] https://live.gnome.org/DenisWashington_GtkBuilder
[2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html
[3] http://git.gnome.org/browse/glade/log/?h=gbinding
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/glade-devel

[Juan Pablo]

Hi Denis, ok good, I will take a look at it next week when I get back from vacations.

Greets

Juan Pablo

Enviado desde mi iPhone

Hi,
I have finally commited all code to fix the bug in the "gbinding" property binding branch that I described earlier (see below). Now all GladeEditor subclasses in plugins/gtk+/ call the newly introduced glade_property_invalidate() function when a property is disabled, which causes all properties bound to the disabled property to be unbound automatically. This means that all situations where the user changes the sensitivity of a property with the inspector are handled correctly now from property binding standpoint.
If there are any other cases where glade_property_invalidate() needs to be called, please let me know.
Regards,
Denis

Post by Denis Washington
Hi,
After an unfortunate longer period of inactivity, I am happy to tell you
that I started to work on bringing GObject property binding support to
Glade again where I left off last summer after GSoC [1]. (By the way, I
passed final evaluation! Thanks to everyone involved! Thank for
mentoring me, Juan! :) This message is intended as a quick update what I
am doing now.
In my last message to this list [2], I mentioned that the current Glade
codebase doesn't record changes to the sensitivity of properties (such
as, e.g., making the "label" property of a GtkButton insensitive when
that button is set to have a custom content widget) in its command
(undo/redo) system, and that this makes it impossible to cleanly
auto-remove property bindings that become invalid this way. Tristan
identified this problem as a blocker to the adoption of the property
binding branch [3] into master, so this is what I'm starting to tackle now.
For this purpose, I created a new branch named "command-set-sensitive"
to convert all relevant property sensitivity changes to undoable
commands. (I am not doing this in the "gbinding" branch directly to
allow for easier isolated reviewing and testing.) The branch introduces
- A new command function, named glade_command_set_property_sensitive(),
which sets the sensitivity of a single property undoably. Being more of
a side effect, this command is always group with other commands (such as
switching the content type of a GtkButton) and should never stand on its
own.
- A new virtual function of GladeWidgetAdaptor,
glade_widget_adaptor_adjust_property_flags(), which can be overridden
for each type of widget to provide a property sensitivity policy. It
accepts a "use_command" boolean parameter which tells the function
whether to use the command system for sensititivity changes or call
glade_widget_property_set_sensitive() directly. (The latter is required
when the widget is first created, or when it is loaded from a file.)
- A port of a small portion of the GTK+ plugin to the new functions as
an example. (Currently, only the GtkEntry-related port is ported.)
I hope that this work enables me to fix the last remaining big blocker
bug before the property binding branch is ready for prime time. Any
Regards,
Denis
[1] https://live.gnome.org/DenisWashington_GtkBuilder
[2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html
[3] http://git.gnome.org/browse/glade/log/?h=gbinding
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/m

[Denis Washington]

Post by Juan Pablo
Hi Denis, ok good, I will take a look at it next week when I get back from vacations.
Greets
Juan Pablo

Did you get to that yet?

Regards,
Denis

Post by Juan Pablo
Enviado desde mi iPhone

Hi,
I have finally commited all code to fix the bug in the "gbinding" property binding branch that I described earlier (see below). Now all GladeEditor subclasses in plugins/gtk+/ call the newly introduced glade_property_invalidate() function when a property is disabled, which causes all properties bound to the disabled property to be unbound automatically. This means that all situations where the user changes the sensitivity of a property with the inspector are handled correctly now from property binding standpoint.
If there are any other cases where glade_property_invalidate() needs to be called, please let me know.
Regards,
Denis

Post by Denis Washington
Hi,
After an unfortunate longer period of inactivity, I am happy to tell you
that I started to work on bringing GObject property binding support to
Glade again where I left off last summer after GSoC [1]. (By the way, I
passed final evaluation! Thanks to everyone involved! Thank for
mentoring me, Juan! :) This message is intended as a quick update what I
am doing now.
In my last message to this list [2], I mentioned that the current Glade
codebase doesn't record changes to the sensitivity of properties (such
as, e.g., making the "label" property of a GtkButton insensitive when
that button is set to have a custom content widget) in its command
(undo/redo) system, and that this makes it impossible to cleanly
auto-remove property bindings that become invalid this way. Tristan
identified this problem as a blocker to the adoption of the property
binding branch [3] into master, so this is what I'm starting to tackle now.
For this purpose, I created a new branch named "command-set-sensitive"
to convert all relevant property sensitivity changes to undoable
commands. (I am not doing this in the "gbinding" branch directly to
allow for easier isolated reviewing and testing.) The branch introduces
- A new command function, named glade_command_set_property_sensitive(),
which sets the sensitivity of a single property undoably. Being more of
a side effect, this command is always group with other commands (such as
switching the content type of a GtkButton) and should never stand on its
own.
- A new virtual function of GladeWidgetAdaptor,
glade_widget_adaptor_adjust_property_flags(), which can be overridden
for each type of widget to provide a property sensitivity policy. It
accepts a "use_command" boolean parameter which tells the function
whether to use the command system for sensititivity changes or call
glade_widget_property_set_sensitive() directly. (The latter is required
when the widget is first created, or when it is loaded from a file.)
- A port of a small portion of the GTK+ plugin to the new functions as
an example. (Currently, only the GtkEntry-related port is ported.)
I hope that this work enables me to fix the last remaining big blocker
bug before the property binding branch is ready for prime time. Any
Regards,
Denis
[1] https://live.gnome.org/DenisWashington_GtkBuilder
[2] http://lists.ximian.com/pipermail/glade-devel/2011-September/001902.html
[3] http://git.gnome.org/browse/glade/log/?h=gbinding
_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
http://lists.ximian.com/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/g