[Laszlo-dev] How should states _really_ work?

[Sarah Allen]

Interesting question! cc'ing Laszlo-user list, since LZX coders on there 
might have some thoughts on this, or at least be interested in the 
details of how states  work and whether that should be changed in the 
future.  I did a little experimentation (see below) to remind myself how 
states work, and recall a little history of how we got to where we are.  
I do like the current behavior (the convenience of implementing 
dragstate and friends), but I do admit that some of the nuances of 
states can be confusing and I don't know if they are clearly documented.

The question is: should contraints that are overridden when a state is 
applies be "put back" when a state is removed?

Conceptually when you apply a state, a bunch of stuff is added, and when 
you remove it that stuff is removed; however, states are allowed to have 
side effects, when attributes are modified by a state they stay 
modified.  So, attributes and methods when applied remain as side 
effects; however, views and events are temporal and get removed.  Way 
back in LPS v1, Adam Wolff and I decided that constraints are 
conceptually like attribute values, even if their implementation is more 
like an event; which is why we have the behavior we do today.

In an abstract sense, it feels like a bug that when a state is removed, 
you don't just put everything back the way it was.  If you look at this 
simple example, that might be your expectation:
<canvas>
  <checkbox id="cbox"  text="Show"
            x="10" y="10" />
 
  <state apply="${cbox.value}">
     <view bgcolor="blue" x="5" y="30"
          width="150" height="150" />
  </state>
</canvas>

However, it is a powerful feature of states that you are allowed to 
leave a side-effect behind (which is really what enables the simplicity 
of dragstate and related coding patterns.)  If you change the value of 
an attribute, it stays that way.  In the following example, after 
clicking on the checkbox twice to turn it on and off again, the value of 
the attribute "t" is 10, not it's original value "4"

<canvas>
  <simplelayout/>
  <attribute name="t" value="4"/>
  <text text="${canvas.t}"/>
  <checkbox id="cbox"  text="Show"
            x="10" y="10" />
 
  <state apply="${cbox.value}">
     <attribute name="t" value="10"/>
     <view bgcolor="blue" x="5" y="30"
          width="150" height="150" />
  </state>
</canvas>

Now, I wonder what happens with a method.  In the example below, you 
will see that if I toggle the checkbox on and back off, the state's 
method remains, just like an attribute.

<canvas debug="true">
  <simplelayout/>
  <attribute name="t" value="4"/>
  <text text="${canvas.t}"/>
  <checkbox id="cbox"  text="Show"
            x="10" y="10" />
 
  <state apply="${cbox.value}">
     <attribute name="t" value="10"/>
     <view bgcolor="blue" x="5" y="30"
          width="150" height="150" />
       <method name="doSomething">
          Debug.write('new');
      </method>
  </state>

  <button onclick="canvas.doSomething()">doSomething</button>
  <method name="doSomething">
    Debug.write('orginal');
  </method>
</canvas>

Events, get added and removed like views.  In the example below, you end 
up with two events when the state is applied, then just the original 
event when the state is removed.

<canvas debug="true">
  <simplelayout/>
  <attribute name="t" value="4"/>
  <text text="${canvas.t}"/>
  <checkbox id="cbox"  text="Show"
            x="10" y="10" />
 
  <state apply="${cbox.value}">
     <attribute name="t" value="10"/>
     <view bgcolor="blue" x="5" y="30"
          width="150" height="150" />
       <handler name="onmousedown" reference="LzGlobalMouse">
          Debug.write('new');
      </handler>
  </state>

  <button onclick="canvas.doSomething()">doSomething</button>
  <handler name="onmousedown" reference="LzGlobalMouse">
          Debug.write('original');
  </handler>
</canvas>


P T Withington wrote:
> As part of fixing LPP-631 in r8032, states now remove constraints that 
> they override when applied, and they _restore_ those constraints when 
> removed.  This breaks dragging and resizing of the swf debugger window!
>
> The swf debugger starts out with its dimensions defaulted to a 
> percentage of the canvas.  Percentage values are constraints.  This is 
> nifty, because if you resize your browser window, the debugger window 
> nicely resizes too.
>
> But if you try to drag or resize the window, the drag or resize state 
> gets applied, the window tracks the mouse, but when you let go of the 
> mouse, the state gets removed and the previous percentage constraints 
> are reinstalled, snapping the window back to its starting position.
>
> My question:  Is this a bug in states?  Should they _not_ restore 
> constraints they removed?  Is this a bug in drag/resize states?  
> Should they be overriding the base state behavior of restoring 
> constraints?  Or, is this just a bug in the swf debugger?  Should it 
> only size to the canvas initially and not respond to canvas changes?  
> Or should it be improved to track the canvas until it is resized or 
> dragged?