Max Carlson | 1 Sep 01:33 2010

[Laszlo-reviews] For Review: Change maxcarlson-20100831-WF8 Summary: Fix getAttributeRelative('x/y') calls for scaled views

I'm going to go ahead and commit this one since it's so dead simple/obvious.

Change maxcarlson-20100831-WF8 by maxcarlson <at> friendly on 2010-08-31 16:31:44 PDT
    in /Users/maxcarlson/openlaszlo/trunk2
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Fix getAttributeRelative('x/y') calls for scaled views

Bugs Fixed: LPP-9333 - lz.view getAttributeRelative() doesn't work with nested views inside a view that
has xscale/yscale

Technical Reviewer: ptw
QA Reviewer: kathryn aaker <kathryn <at> kathrynaaker.com>

Details: There was an order of operations bug.  The offset should be added to the x/y _before_ scaling is applied.

Tests: See LPP-9333 in dhtml/swf10

Files:
M       WEB-INF/lps/lfc/views/LaszloView.lzs

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20100831-WF8.tar

promanik | 1 Sep 02:18 2010

Re: [Laszlo-reviews] For Review: Change maxcarlson-20100831-5Uu Summary: Add json2 support for IE 8

Approved!

On Tue, Aug 31, 2010 at 6:53 PM, Max Carlson wrote:

> Change maxcarlson-20100831-5Uu by maxcarlson <at> friendly on 2010-08-31 
> 15:48:49 PDT
>     in /Users/maxcarlson/openlaszlo/trunk2
>     for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: Add json2 support for IE 8
>
> Bugs Fixed: LPP-9336 - IE/html: pmrpc requires JSON library.
>
> Technical Reviewer: promanik
> QA Reviewer: hminsky
>
> Details: pmrpc - Add path
>
> json2 - Add path, license
>
> pmrpc.js - include json2
>
> build.xml - Update dependencies for build.
>
> json2.js - Changed to use RegExp instead of // so it works with our 
> compiler.
>
> Tests: Testcase from LPP-9338 in IE
>
> Files:
(Continue reading)

P T Withington | 1 Sep 17:22 2010

Re: [Laszlo-reviews] For Review: Change maxcarlson-20100831-WF8 Summary: Fix getAttributeRelative('x/y') calls for scaled views

This fixes the reported bug, but I'm still not convinced that the math is completely correct.  Unless I
misunderstand completely, I feel the following two assertions should also hold in the supplied test case:

  assertEquals((yellowview.x+redview.x)*blueview.xscale,
               redview.getAttributeRelative('x', blueview), "red x in blue")
  assertEquals((yellowview.x+redview.x)/(- blueview.xscale),
               blueview.getAttributeRelative('x', redview), "blue x in red")

they currently fail, even with your change applied.

So, I approve your change as far as it goes, but could you either re-open it, or open a new bug, with the above tests?

And also, you implied you had a general test case for getAttributeRelative.  It seems the test from LPP-9333
(and my two additional test cases) should be added to that test.  Is this test a part of lztest?  It would be
good if it was.

On 2010-08-31, at 19:33, Max Carlson wrote:

> I'm going to go ahead and commit this one since it's so dead simple/obvious.
> 
> Change maxcarlson-20100831-WF8 by maxcarlson <at> friendly on 2010-08-31 16:31:44 PDT
>    in /Users/maxcarlson/openlaszlo/trunk2
>    for http://svn.openlaszlo.org/openlaszlo/trunk
> 
> Summary: Fix getAttributeRelative('x/y') calls for scaled views
> 
> Bugs Fixed: LPP-9333 - lz.view getAttributeRelative() doesn't work with nested views inside a view that
has xscale/yscale
> 
> Technical Reviewer: ptw
(Continue reading)

P T Withington | 1 Sep 18:45 2010
Picon

Re: <debug> API

So, should the preferences object become the way you control the debugger and the individual preferences
be deprecated?  I'm leery of having multiple interfaces.  But, the only way I can think of to document the
combined preferences then is to make a separate debugprefs class...  Ugh.

On the 3rd hand, I guess I need something like that so I can get their types right and correctly accept values
out of the preferences object into them.

Kind of a bigger can of worms than I wanted just now...

On 2010-08-31, at 13:25, Max Carlson wrote:

> Sounds good!
> 
> Regards,
> Max Carlson
> OpenLaszlo.org
> 
> On 8/31/10 9:26 AM, P T Withington wrote:
>> I'm working on
>> 
>> LPP-9311 flash halts in backtrace mode but not in debug mode when dealing with deeply nested views
>> 
>> and one piece of the puzzle (I think) is to ensure that the debugger's notion of maximum stack depth is
within the underlying runtime's limit.  In the case of SWF, we have a canvas property `scriptlimits` that
lets you specify the maximum recursion and timeout values for the player.  (See LPP-6132
debug.backtraceStack.maxDepth attribute should be copied form scriptlimits recursion depth).
>> 
>> To do this, I plan to pass a debugger `preferences` object through the console window (as embodied by
the<debug>  tag).  Since I'm in there, I figure I might as well surface this in the tag, so you will be able to
say things like:
(Continue reading)

Henry Minsky | 1 Sep 18:50 2010
Picon

Re: <debug> API

I don't know think that too many people are actually using the exising <debug> tag attributes, except for width and height and x, y on the view...


On Wed, Sep 1, 2010 at 9:45 AM, P T Withington <ptw <at> pobox.com> wrote:
So, should the preferences object become the way you control the debugger and the individual preferences be deprecated?  I'm leery of having multiple interfaces.  But, the only way I can think of to document the combined preferences then is to make a separate debugprefs class...  Ugh.

On the 3rd hand, I guess I need something like that so I can get their types right and correctly accept values out of the preferences object into them.

Kind of a bigger can of worms than I wanted just now...

On 2010-08-31, at 13:25, Max Carlson wrote:

> Sounds good!
>
> Regards,
> Max Carlson
> OpenLaszlo.org
>
> On 8/31/10 9:26 AM, P T Withington wrote:
>> I'm working on
>>
>> LPP-9311 flash halts in backtrace mode but not in debug mode when dealing with deeply nested views
>>
>> and one piece of the puzzle (I think) is to ensure that the debugger's notion of maximum stack depth is within the underlying runtime's limit.  In the case of SWF, we have a canvas property `scriptlimits` that lets you specify the maximum recursion and timeout values for the player.  (See LPP-6132 debug.backtraceStack.maxDepth attribute should be copied form scriptlimits recursion depth).
>>
>> To do this, I plan to pass a debugger `preferences` object through the console window (as embodied by the<debug>  tag).  Since I'm in there, I figure I might as well surface this in the tag, so you will be able to say things like:
>>
>> <debug ... preferences="print-length: 256, print-depth:32, show-internal-properties: true" />
>>
>> My thought is to compile the preferences as a CSS properties list and use the normal CSS mapping of hyphens to camel case, e.g.:
>>
>>   camel-case ->  camelCase
>>
>> to translate CSS properties to debugger attributes.
>>
>> Comments?





--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com


Max Carlson | 1 Sep 19:19 2010

Re: <debug> API

Yeah, I think it's okay to change these APIs.  Were they documented?  If 
not, they're completely free game...

Regards,
Max Carlson
OpenLaszlo.org

On 9/1/10 9:50 AM, Henry Minsky wrote:
> I don't know think that too many people are actually using the exising
> <debug> tag attributes, except for width and height and x, y on the view...
>
>
> On Wed, Sep 1, 2010 at 9:45 AM, P T Withington <ptw <at> pobox.com
> <mailto:ptw <at> pobox.com>> wrote:
>
>     So, should the preferences object become the way you control the
>     debugger and the individual preferences be deprecated?  I'm leery of
>     having multiple interfaces.  But, the only way I can think of to
>     document the combined preferences then is to make a separate
>     debugprefs class...  Ugh.
>
>     On the 3rd hand, I guess I need something like that so I can get
>     their types right and correctly accept values out of the preferences
>     object into them.
>
>     Kind of a bigger can of worms than I wanted just now...
>
>     On 2010-08-31, at 13:25, Max Carlson wrote:
>
>      > Sounds good!
>      >
>      > Regards,
>      > Max Carlson
>      > OpenLaszlo.org
>      >
>      > On 8/31/10 9:26 AM, P T Withington wrote:
>      >> I'm working on
>      >>
>      >> LPP-9311 flash halts in backtrace mode but not in debug mode
>     when dealing with deeply nested views
>      >>
>      >> and one piece of the puzzle (I think) is to ensure that the
>     debugger's notion of maximum stack depth is within the underlying
>     runtime's limit.  In the case of SWF, we have a canvas property
>     `scriptlimits` that lets you specify the maximum recursion and
>     timeout values for the player.  (See LPP-6132
>     debug.backtraceStack.maxDepth attribute should be copied form
>     scriptlimits recursion depth).
>      >>
>      >> To do this, I plan to pass a debugger `preferences` object
>     through the console window (as embodied by the<debug>  tag).  Since
>     I'm in there, I figure I might as well surface this in the tag, so
>     you will be able to say things like:
>      >>
>      >> <debug ... preferences="print-length: 256, print-depth:32,
>     show-internal-properties: true" />
>      >>
>      >> My thought is to compile the preferences as a CSS properties
>     list and use the normal CSS mapping of hyphens to camel case, e.g.:
>      >>
>      >>   camel-case ->  camelCase
>      >>
>      >> to translate CSS properties to debugger attributes.
>      >>
>      >> Comments?
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com <mailto:hminsky <at> laszlosystems.com>
>
>

P T Withington | 1 Sep 19:49 2010
Picon

Re: <debug> API

Unfortunately, they're already documented:

http://labs.openlaszlo.org/trunk-nightly/docs/reference/lz.DebugService+debug.html

but I guess they are little known...

On 2010-09-01, at 13:19, Max Carlson wrote:

> Yeah, I think it's okay to change these APIs.  Were they documented?  If not, they're completely free game...
> 
> Regards,
> Max Carlson
> OpenLaszlo.org
> 
> On 9/1/10 9:50 AM, Henry Minsky wrote:
>> I don't know think that too many people are actually using the exising
>> <debug> tag attributes, except for width and height and x, y on the view...
>> 
>> 
>> On Wed, Sep 1, 2010 at 9:45 AM, P T Withington <ptw <at> pobox.com
>> <mailto:ptw <at> pobox.com>> wrote:
>> 
>>    So, should the preferences object become the way you control the
>>    debugger and the individual preferences be deprecated?  I'm leery of
>>    having multiple interfaces.  But, the only way I can think of to
>>    document the combined preferences then is to make a separate
>>    debugprefs class...  Ugh.
>> 
>>    On the 3rd hand, I guess I need something like that so I can get
>>    their types right and correctly accept values out of the preferences
>>    object into them.
>> 
>>    Kind of a bigger can of worms than I wanted just now...
>> 
>>    On 2010-08-31, at 13:25, Max Carlson wrote:
>> 
>>     > Sounds good!
>>     >
>>     > Regards,
>>     > Max Carlson
>>     > OpenLaszlo.org
>>     >
>>     > On 8/31/10 9:26 AM, P T Withington wrote:
>>     >> I'm working on
>>     >>
>>     >> LPP-9311 flash halts in backtrace mode but not in debug mode
>>    when dealing with deeply nested views
>>     >>
>>     >> and one piece of the puzzle (I think) is to ensure that the
>>    debugger's notion of maximum stack depth is within the underlying
>>    runtime's limit.  In the case of SWF, we have a canvas property
>>    `scriptlimits` that lets you specify the maximum recursion and
>>    timeout values for the player.  (See LPP-6132
>>    debug.backtraceStack.maxDepth attribute should be copied form
>>    scriptlimits recursion depth).
>>     >>
>>     >> To do this, I plan to pass a debugger `preferences` object
>>    through the console window (as embodied by the<debug>  tag).  Since
>>    I'm in there, I figure I might as well surface this in the tag, so
>>    you will be able to say things like:
>>     >>
>>     >> <debug ... preferences="print-length: 256, print-depth:32,
>>    show-internal-properties: true" />
>>     >>
>>     >> My thought is to compile the preferences as a CSS properties
>>    list and use the normal CSS mapping of hyphens to camel case, e.g.:
>>     >>
>>     >>   camel-case ->  camelCase
>>     >>
>>     >> to translate CSS properties to debugger attributes.
>>     >>
>>     >> Comments?
>> 
>> 
>> 
>> 
>> 
>> --
>> Henry Minsky
>> Software Architect
>> hminsky <at> laszlosystems.com <mailto:hminsky <at> laszlosystems.com>
>> 
>> 

Max Carlson | 1 Sep 21:43 2010

[Laszlo-reviews] For Review: Change maxcarlson-20100901-29o Summary: Fix lz.contextmenu.showBuiltInItems()

Change maxcarlson-20100901-29o by maxcarlson <at> friendly on 2010-09-01 12:37:21 PDT
    in /Users/maxcarlson/openlaszlo/trunk2
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Fix lz.contextmenu.showBuiltInItems()

Bugs Fixed: LPP-9291 - DHTML: provide way to show browser context-menu (regression)

Technical Reviewer: andre.bargull <at> udo.edu
QA Reviewer: hminsky

Details: Pay attention to flag set by showBuiltInItems() when deciding to suppress the browser's
built-in context menus.

Tests: See LPP-9291

Files:
M       WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20100901-29o.tar

Max Carlson | 1 Sep 22:05 2010

Re: <debug> API

Hrm.  In that case, why not add style declarations to the attributes and 
apply the preferences using the new style attribute?

Regards,
Max Carlson
OpenLaszlo.org

On 9/1/10 10:49 AM, P T Withington wrote:
> Unfortunately, they're already documented:
>
> http://labs.openlaszlo.org/trunk-nightly/docs/reference/lz.DebugService+debug.html
>
> but I guess they are little known...
>
> On 2010-09-01, at 13:19, Max Carlson wrote:
>
>> Yeah, I think it's okay to change these APIs.  Were they documented?  If not, they're completely free game...
>>
>> Regards,
>> Max Carlson
>> OpenLaszlo.org
>>
>> On 9/1/10 9:50 AM, Henry Minsky wrote:
>>> I don't know think that too many people are actually using the exising
>>> <debug>  tag attributes, except for width and height and x, y on the view...
>>>
>>>
>>> On Wed, Sep 1, 2010 at 9:45 AM, P T Withington<ptw <at> pobox.com
>>> <mailto:ptw <at> pobox.com>>  wrote:
>>>
>>>     So, should the preferences object become the way you control the
>>>     debugger and the individual preferences be deprecated?  I'm leery of
>>>     having multiple interfaces.  But, the only way I can think of to
>>>     document the combined preferences then is to make a separate
>>>     debugprefs class...  Ugh.
>>>
>>>     On the 3rd hand, I guess I need something like that so I can get
>>>     their types right and correctly accept values out of the preferences
>>>     object into them.
>>>
>>>     Kind of a bigger can of worms than I wanted just now...
>>>
>>>     On 2010-08-31, at 13:25, Max Carlson wrote:
>>>
>>>      >  Sounds good!
>>>      >
>>>      >  Regards,
>>>      >  Max Carlson
>>>      >  OpenLaszlo.org
>>>      >
>>>      >  On 8/31/10 9:26 AM, P T Withington wrote:
>>>      >>  I'm working on
>>>      >>
>>>      >>  LPP-9311 flash halts in backtrace mode but not in debug mode
>>>     when dealing with deeply nested views
>>>      >>
>>>      >>  and one piece of the puzzle (I think) is to ensure that the
>>>     debugger's notion of maximum stack depth is within the underlying
>>>     runtime's limit.  In the case of SWF, we have a canvas property
>>>     `scriptlimits` that lets you specify the maximum recursion and
>>>     timeout values for the player.  (See LPP-6132
>>>     debug.backtraceStack.maxDepth attribute should be copied form
>>>     scriptlimits recursion depth).
>>>      >>
>>>      >>  To do this, I plan to pass a debugger `preferences` object
>>>     through the console window (as embodied by the<debug>   tag).  Since
>>>     I'm in there, I figure I might as well surface this in the tag, so
>>>     you will be able to say things like:
>>>      >>
>>>      >>  <debug ... preferences="print-length: 256, print-depth:32,
>>>     show-internal-properties: true" />
>>>      >>
>>>      >>  My thought is to compile the preferences as a CSS properties
>>>     list and use the normal CSS mapping of hyphens to camel case, e.g.:
>>>      >>
>>>      >>    camel-case ->   camelCase
>>>      >>
>>>      >>  to translate CSS properties to debugger attributes.
>>>      >>
>>>      >>  Comments?
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> hminsky <at> laszlosystems.com<mailto:hminsky <at> laszlosystems.com>
>>>
>>>
>

Henry Minsky | 1 Sep 23:13 2010

Re: [Laszlo-reviews] For Review: Change maxcarlson-20100901-29o Summary: Fix lz.contextmenu.showBuiltInItems()

approved

On Wed, Sep 1, 2010 at 12:43 PM, Max Carlson <max <at> openlaszlo.org> wrote:
Change maxcarlson-20100901-29o by maxcarlson <at> friendly on 2010-09-01 12:37:21 PDT
   in /Users/maxcarlson/openlaszlo/trunk2
   for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Fix lz.contextmenu.showBuiltInItems()

Bugs Fixed: LPP-9291 - DHTML: provide way to show browser context-menu (regression)

Technical Reviewer: andre.bargull <at> udo.edu
QA Reviewer: hminsky

Details: Pay attention to flag set by showBuiltInItems() when deciding to suppress the browser's built-in context menus.

Tests: See LPP-9291

Files:
M       WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20100901-29o.tar



--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com



Gmane