Approved.
What I meant here:
> 2) Your change here implies the old code was broken?
>
> - var xscale = this.unstretchedwidth == 0 ? 100 :
> v/this.unstretchedwidth;
> - this._xscale = xscale;
> + if (this.capabilities.scaling) {
> + this.$lzc$set_xscale(this.unstretchedwidth == 0 ? 1 :
> v/this.unstretchedwidth);
> + }
>
> The old code was legacy left over from before we factored out the swf8
> kernel. I figured we'd want to add scaling back in eventually, so I left
> these in. Since scaling is now based on a factor of 1 instead of 100, this
> change makes sense.
Is that the old code must surely have been broken, because on one side of the
`:` it used `100` (as in percent) to mean "don't scale" and on the other side
it is using a fraction (new width divided by the unscaled width). You adjusted
the 100 to 1 and left the other side alone, which seems correct; but leaves me
wondering how the old code ever worked...
On 2010-08-13, at 20:08, Max Carlson wrote:
> Change 20100811-maxcarlson-t by [email protected] on 2010-08-11
> 12:53:33 MDT
> in /Users/maxcarlson/openlaszlo/trunk-clean
> for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: UPDATED: Add xscale any yscale attributes to view
>
> New Features: View.xscale and yscale will scale a view and all its children.
> Check capabilities.scaling to be sure your runtime supports this feature.
>
> Bugs Fixed: LPP-9272 - Add way to scale views
>
> Technical Reviewer: ptw
> QA Reviewer: hminsky
>
> Details: Updated to address Tucker's comments:
>
> 1) Henry already spotted a type-oh where x and y are mixed.
>
> Fixed.
>
> 2) onxscale/onyscale: The convention is for these to be private since they
> are implicit events associated with the corresponding attribute.
>
> Fixed.
>
> 3) I also think a good convention is to put the virtual attribute, setter,
> and implicit event all together in the source.
>
> Fixed.
>
> 4) This looks wrong:
>
> - stylenames.transform = 'WebkitTransform';
> + stylenames.scaling = 'WebkitTransform';
>
> because stylenames.transform is used in __updateTransform.
>
> Doe! Fixed.
>
> Questions:
>
> 1) The CSS transform style allows you to build up various transformations and
> is order-sensitive, it seems the SWF implementation must have a specified
> order? So you have implemented a compatible order? I.e., scaling happens
> before rotation, so it is in the axes of the original?
>
> I think my order is compatible because the testcase looks the same across
> runtimes. I couldn't find specific documentation about what order Flash
> applies these in.
>
> 2) Your change here implies the old code was broken?
>
> - var xscale = this.unstretchedwidth == 0 ? 100 :
> v/this.unstretchedwidth;
> - this._xscale = xscale;
> + if (this.capabilities.scaling) {
> + this.$lzc$set_xscale(this.unstretchedwidth == 0 ? 1 :
> v/this.unstretchedwidth);
> + }
>
> The old code was legacy left over from before we factored out the swf8
> kernel. I figured we'd want to add scaling back in eventually, so I left
> these in. Since scaling is now based on a factor of 1 instead of 100, this
> change makes sense.
>
> Otherwise, the same:
>
> LzSprite.as - Add scaling capability, set to true, add implementations of
> setXScale() and setYScale().
>
> LzSprite.js - Add scaling capability, set to true where available, add
> implementations of setXScale() and setYScale(). Refactor setRotation() to
> handle multiple simultaneous transforms.
>
> swf9/LzSprite.as - Add scaling capability, set to true, add implementations
> of setXScale() and setYScale().
>
> LaszloView - Add attributes, events and setters for xscale, yscale. Update
> bounds computation code to factor in scaling.
>
> Tests: See testcase at LPP-9272
>
> Files:
> M WEB-INF/lps/lfc/kernel/swf/LzSprite.as
> M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
> M WEB-INF/lps/lfc/kernel/swf9/LzSprite.as
> M WEB-INF/lps/lfc/views/LaszloView.lzs
>
> Changeset:
> http://svn.openlaszlo.org/openlaszlo/patches/20100811-maxcarlson-t.tar
