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

[Denis Washington]

Am 22.11.2011 06:47, schrieb 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

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

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

> And... thanks a lot for your patience with this.

No problem. :)

Regards,
Denis