proposal to integrate release notes improvements to OL4B1 branch

The 4.0b1rc1 build was at r3153. Since then, there have been quite a  
few release note updates (go John!), which I propose integrating to  
the 4.0b1 branch for inclusion in the 4.0b1 release. I don't think  
there is an LPP bug tracking this work -- john, is there?

------------------------------------------------------------------------
r3153 | jsundman | 2006-12-20 12:00:52 -0800 (Wed, 20 Dec 2006) | 1 line

checkpointing release notes.  Including David's markup and several  
suggestions from Jim.
------------------------------------------------------------------------
r3158 | jsundman | 2006-12-20 18:04:50 -0800 (Wed, 20 Dec 2006) | 1 line

more cosmetic and content cleanup to the release notes.  
Asymptotically approaching useful notes, I do hope. Another update  
coming in about 8 hours.  Suggest waiting until then before reviewing.
------------------------------------------------------------------------
r3163 | jsundman | 2006-12-21 06:16:41 -0800 (Thu, 21 Dec 2006) | 1 line

another release notes checkpoint. Work continues.
------------------------------------------------------------------------
r3166 | jsundman | 2006-12-21 10:08:06 -0800 (Thu, 21 Dec 2006) | 1 line

another checkpoint. Structure is nearly in place.  Still working.
------------------------------------------------------------------------
r3169 | jsundman | 2006-12-21 11:50:58 -0800 (Thu, 21 Dec 2006) | 1 line

Release notes for OL4B1 release candidate.  Take 'em away!
------------------------------------------------------------------------

Re: proposal to integrate release notes improvements to OL4B1 branch

http://www.openlaszlo.org/jira/browse/LPP-3185

On Jan 1, 2007, at 12:31 PM, Benjamin Shine wrote:

>
> The 4.0b1rc1 build was at r3153. Since then, there have been quite  
> a few release note updates (go John!), which I propose integrating  
> to the 4.0b1 branch for inclusion in the 4.0b1 release. I don't  
> think there is an LPP bug tracking this work -- john, is there?
>
> ---------------------------------------------------------------------- 
> --
> r3153 | jsundman | 2006-12-20 12:00:52 -0800 (Wed, 20 Dec 2006) | 1  
> line
>
> checkpointing release notes.  Including David's markup and several  
> suggestions from Jim.
> ---------------------------------------------------------------------- 
> --
> r3158 | jsundman | 2006-12-20 18:04:50 -0800 (Wed, 20 Dec 2006) | 1  
> line
>
> more cosmetic and content cleanup to the release notes.  
> Asymptotically approaching useful notes, I do hope. Another update  
> coming in about 8 hours.  Suggest waiting until then before reviewing.
> ---------------------------------------------------------------------- 
> --
> r3163 | jsundman | 2006-12-21 06:16:41 -0800 (Thu, 21 Dec 2006) | 1  
> line
>

Re: For Review: Change 20061221-papley-w Summary: Make it possible for lzc to be run from any directory. Files references will be relative

Comments:

1) In DHTMLWriter: File.separator.charAt(0) is more simply written  
File.separatorChar, I believe.

2) I'm confused as to why the result of FileUtils.relativePath has to  
be checked to see if it is not a relative path.  Is this method mis- 
named, or broken?  Ad if the latter, perhaps it should be fixed,  
rather than cleaning up after calling it.

3) Am I correct that the crux of the fix is for FileResolver to  
actually resolve files to absolute paths?

Otherwise, approved.

On 2006-12-21, at 23:18 EST, Phillip George Apley wrote:

> Change 20061221-papley-w by papley <at> pgapbg417.home on 2006-12-21  
> 22:17:02 EST
>     in /Users/papley/src/svn/legals
>
> Summary: Make it possible for lzc to be run from any directory.  
> Files references will be relative
> 	 to the directory the .lzx application is in, rather than from  
> $LPS_HOME, even if lzc is
> 	 called in a parent directory of the one containing the .lzx file.
>
> 		~/src/svn/legals: lzc examples/image-loading/dataimage.lzx
> 		~/src/svn/legals/examples: lzc image-loading/dataimage.lzx
> 		~/src/svn/legals/examples/image-loading: lzc dataimage.lzx

Re: For Review: Change 20061229-ben-a Summary: CSS can be imported relative to source file, not main lzx file

Comments:

1) Is it really the case that CSS files should be resolved against  
the application base?  Or should they always be resolved against the  
file they are declared in?  I believe the latter is what HTML does.   
That would simplify the logic here.

Otherwise, approved.

On 2006-12-29, at 18:03 EST, Benjamin Shine wrote:

> Change 20061229-ben-a by ben <at> bens-g5.local on 2006-12-29 14:48:39 PST
>     in /Users/ben/src/svn/openlaszlo/trunk
>
> Summary: CSS can be imported relative to source file, not main lzx  
> file
>
> New Features:
>
> Bugs Fixed: LPP-3042 CSS import is relative to main LZX file
>
> Technical Reviewer: ptw (pending)
> QA Reviewer: pkang (pending)
> Doc Reviewer: frisco (pending)
>
> Documentation:
>
> Previously all css files had to be relative to the application  
> file; now the
> first place the compiler will search for a css file is relative to  

For Review: Change 20070101-Philip-2 Summary: Modify view/text methods to match documented behavior.

Change 20070101-Philip-2 by Philip <at> Philip-DC on 2007-01-01 16:13:41 EST
     in /cygdrive/f/laszlo/svn/src/svn/openlaszlo/branches/legals

Summary: Modify view/text methods to match documented behavior.

New Features:

Bugs Fixed: LPP-3376

Technical Reviewer: max
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
In LzView, modified sendInFrontOf() and sendToBack() to accept a null 
argument. This matches the documented behavior of the method (and it's 
called this way from the charting package).

In LzText, modified setFontName() and setFontSize() to call setText to 
recompute the width and height. This matches the behavior in trunk. Without 
this change, some charting demos display an incorrect border around some 
text labels.

Tests:
Running the charting tests get further.

For Review: Change 20070102-Philip-6 Summary: Change 'classname' to 'constructor.tagname'

Change 20070102-Philip-6 by Philip <at> Philip-DC on 2007-01-02 10:38:09 EST
     in /cygdrive/f/laszlo/svn/src/svn/openlaszlo/branches/legals

Summary: Change 'classname' to 'constructor.tagname'

New Features:

Bugs Fixed:

Technical Reviewer: ptw
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
Charting package needs to be upgraded to run on legals. this.classname 
doesn't exist on legals. this.constructor.tagname (or 
this.constructor.classname) is used instead.

Tests:

Files:
M      lps/components/charts/styles/styleparser.lzx
M      lps/components/charts/styles/chartstyle.lzx
M      lps/components/charts/common/horizontalaxis.lzx
M      lps/components/charts/common/dataseries.lzx
M      lps/components/charts/common/legend.lzx

For Review: Change 20070102-Philip-8: Summary: Misc. charting updates

Change 20070102-Philip-8 by Philip <at> Philip-DC on 2007-01-02 11:11:18 EST
     in /cygdrive/f/laszlo/svn/src/svn/openlaszlo/branches/legals

Summary: Misc. charting updates

New Features:

Bugs Fixed:

Technical Reviewer: ptw
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:
Test for existence of LzFontManager (only defined in swf, not dhtml). Added 
various null tests to make it easier to debug charting.

Release Notes:

Details:

Tests:
Simple charting tests now run. Charting in dhtml runs further.

Files:
M      lps/components/charts/common/label.lzx
M      lps/components/charts/common/rectangularchart.lzx
M      lps/components/charts/linechart/linechart.lzx
M      lps/components/charts/linechart/linechartplotarea.lzx

Question about constructing LzDataset inside methods

Hi Tucker,

I'm tracking down issues with charting in legals and found some references 
to LzDataset that don't appear correct. In two places (dataseries.lzx) an 
LzDataset object is created using this syntax:

     ds = new LzDataset("legendds");

Unless there is another constructor I'm not aware of, the string is being 
passed as the parent object. It looks like this works by luck because the 
LzDataset constructor avoids using or storing the string.

Shouldn't this line be better written as,

     ds = new LzDataset(this, { name: "legendds" });

Thanks!

Phil

error in legals when running examples/animation/animation.lzx in DHTML

Re: error in legals when running examples/animation/animation.lzx in DHTML

Is this possibly due to the constraint-queuing change, which is in  
legals but not b1?

On 2007-01-02, at 12:11 EST, Henry Minsky wrote:

> I am getting this error in Legals when I try to run the
> animation.lzxexample in DHTML:
>
> this.flist has no properties
>
>
> It appears to be in this method of the menu component
>
>        <!-- instantiate children of menu in its floatinglist  
> instead of
> itself.
>             this method is called autmatically.
>             @param array childrenarray: an array of nodes to be
> created-->
>        <method name="createChildren" args="childrenarray" ><![CDATA[
>            this.flist.createChildren(childrenarray);
>        ]]></method>
>
> So now flist is unbound? But this works in 4.0b1. Did something  
> change in
> ordering of setting of init values ?
>
>
> Also, should a component really be calling LzNode.createChildren  
> method at
> all?
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com