On 2009-01-11, at 11:27EST, André Bargull wrote:
On 1/11/2009 4:04 PM, P T Withington wrote:>
It's generally a mess. I don't think anyone has thought out what
really ought to happen, instead, the mechanism has just sort of
evolved as applications have needed to do different things. The
debugger console window is a really good test case, because we
really want some default constraints, but those should be
overridable by use values _or_ constraints, and on top of that,
when the drag or resize states come into play, you really want to
remove _any_ constraint (default class or instance).
Would it help if both instance and class constraints were removed
when a state is applied? That way you can install a default
constraint (can be done in the class), this can be overridden by an
instance value (both constant and constraint) through the normal
override behaviour in LzNode and you don't get any problems when one
of the states get applied.
Yes, that would make my original proposal to Henry, that when the
resize state was applied it would simple define x/y to be their
current values (thereby removing any constraint) work. It did not
work because the constraint on x/y was a class constraint.
If we did make states remove class constraints too, then I think we
could keep __LZhasConstraint private (and not have to provide any
additional mechanisms for removing constraints).
Then the programmer model for the LZX programmer becomes quite simple:
1. A class can give an attribute an initial value, which may be a
constant or a constraint.
2. A subclass or instance can override an attribute initial value,
again with either a constant or constraint.
3. A state (when applied) can override both 1 and 2, again with a
constant or constraint.
Our current understanding is that when a state is removed, it does not
'reveal' the value that it overrode (whether constant or constraint),
it simply leaves the attribute with its current value.
---
I think this is a nice model because you never have to write anything
but a declarative
<attribute name=... value=... />
to manipulate an attribute.
The way you override a constraint on an attribute is to override the
attribute with a new value.
The way to dynamically do that, is to put your override in a state.
---
The only question is, whether we would break something with this more
uniform model. I'm betting we would not. It's possible that this
model is more how 3.x worked (whether by design or by accident). But
I certainly like the simplicity of the programmer model this provides!
