Can you explain what you mean here? Are you saying that it should be an error at the LFC API to use scaling and stretches? Or are you saying the error is at the kernel API?
In either case, it seems like there should be more to this change to fix it. Either you should give an error at the LFC API if both a used, or you should simplify the kernel API so (for instance) the scaling API is the only API and the LFC API is just two different ways of specifying the same thing (as you did with transform and tint). I understand that the stretches API is a nice shortcut for what would be a complex constraint on scale, so I'm fine with that additional API at the LFC level. But we shouldn't have to be providing 'convenience' API's at the kernel level. There we should strive for simplicity, to make it easier to port and more likely to be correct. On 2010-08-17, at 18:21, Max Carlson wrote: > Change maxcarlson-20100817-dBG by maxcarl...@friendly on 2010-08-17 15:12:43 > PDT > in /Users/maxcarlson/openlaszlo/trunk2 > for http://svn.openlaszlo.org/openlaszlo/trunk > > Summary: Fix stretches behavior > > Bugs Fixed: LPP-9292 - Add way to scale views > > Technical Reviewer: hminsky > QA Reviewer: ptw > > Details: I'm checking this in ahead of time, as it's a pretty serious > regression... > > Scaling shouldn't be used in addition to stretches. Removed all scaling > update code, since it's now reserved for user calls, e.g. > setAttribute('xscale', 2); > > Tests: my-apps/copy-of-hello.lzx?lzr=dhtml&lzt=html&debug=true shows debugger > window correctly, testcase at LPP-9292 runs like before. > > Files: > M WEB-INF/lps/lfc/views/LaszloView.lzs > > Changeset: > http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20100817-dBG.tar
