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

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

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

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
because we are too lazy to do things properly, then we add adaptor methods
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
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. :)


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