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