Benjamin Shine | 1 Oct 02:30 2006

For Review: Change change.Ud7vlXQzH.txt Summary: Improve startup animation

Change change.Ud7vlXQzH.txt by ben <at> cooper.local /Users/ben/src/svn/ 
openlaszlo/branches/legals on 2006-09-30 17:22:00 PDT

Summary: Improve startup animation

New Features:

Bugs Fixed:

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

Documentation:
This change makes the startup sequence look right, but less fancy.  
Instead of a load percentage indicator, this just shows a still image  
(captured from the swf that had been used for loading) while the app  
is loading. This change also tweaks the startup animations to be a  
bit slower so we have a chance of seeing >1 frames of it in DHTML.

Release Notes:

Details:

Tests:

Files:
M      demos/lzpix/data/canned_favorites.xml
M      demos/calendar/calendar.lzx
M      demos/calendar/loading.lzx
(Continue reading)

Benjamin Shine | 1 Oct 02:46 2006

Re: For Review: Change change.Ud7vlXQzH.txt Summary: Improve startup animation

I didn't mean to include the change to demos/lzpix/data/ 
canned_favorites.xml. Please ignore that part of the patch.

On Sep 30, 2006, at 5:30 PM, Benjamin Shine wrote:

> Change change.Ud7vlXQzH.txt by ben <at> cooper.local /Users/ben/src/svn/ 
> openlaszlo/branches/legals on 2006-09-30 17:22:00 PDT
>
> Summary: Improve startup animation
>
> New Features:
>
> Bugs Fixed:
>
> Technical Reviewer: minsky
> QA Reviewer: (pending)
> Doc Reviewer: (pending)
>
> Documentation:
> This change makes the startup sequence look right, but less fancy.  
> Instead of a load percentage indicator, this just shows a still  
> image (captured from the swf that had been used for loading) while  
> the app is loading. This change also tweaks the startup animations  
> to be a bit slower so we have a chance of seeing >1 frames of it in  
> DHTML.
>
> Release Notes:
>
> Details:
>
(Continue reading)

Benjamin Shine | 1 Oct 03:14 2006

Re: For Review: Change change.C6vFh0Zaf.txt Summary: Port LvViewLinkage to DHTML

Calendar does a whole bunch of text measurement. For instance in the  
monthtitle button:
                 <method event="ontext">
                     this.setX( Math.round( ( this.parent.width -
                                this.getTextWidth())/2.0) - 2);
                     this.setWidth (this.getTextWidth()+2);
                     this.parent.monthtitleshdw.setWidth  
(this.getTextWidth()+2);

                 </method>
Can this all be replaced with something simpler and faster?

On Sep 29, 2006, at 4:00 PM, Max Carlson wrote:

> Comments:
> * There is no x/yscaling in DHTML...
>
> * _x/yscale are flash-specific properties - you probably want to  
> read it out of the sprite as it'll be undefined here:
> +    var scale = "_" + xory + "scale";
>
> * These should use kernel API calls instead of if ($as2):
> + if ($as2) {
> +        if ((a.sprite.__LZmovieClipRef[scale] / 100) != a[scale]) {
> +          Debug.error("%s != %s", a.sprite.__LZmovieClipRef 
> [scale] / 100, a[scale]);
> +        }
> +      }
> ..
> +      if ($as2) {
(Continue reading)

P T Withington | 1 Oct 04:39 2006

Re: For Review: Change change.C6vFh0Zaf.txt Summary: Port LvViewLinkage to DHTML

Well certainly you could not call getTextWidth 3 times.  If the text  
element is resizable, I believe that when you set the text it will  
have its .width set.  You could verify that .width == getTextWidth,  
and if so, replace the call with an accessor.

It is possible that getTextWidth is from days gone by...

On 2006-09-30, at 21:14 EDT, Benjamin Shine wrote:

> Calendar does a whole bunch of text measurement. For instance in the
> monthtitle button:
>                  <method event="ontext">
>                      this.setX( Math.round( ( this.parent.width -
>                                 this.getTextWidth())/2.0) - 2);
>                      this.setWidth (this.getTextWidth()+2);
>                      this.parent.monthtitleshdw.setWidth
> (this.getTextWidth()+2);
>
>                  </method>
> Can this all be replaced with something simpler and faster?
>
> On Sep 29, 2006, at 4:00 PM, Max Carlson wrote:
>
>> Comments:
>> * There is no x/yscaling in DHTML...
>>
>> * _x/yscale are flash-specific properties - you probably want to
>> read it out of the sprite as it'll be undefined here:
>> +    var scale = "_" + xory + "scale";
>>
(Continue reading)

Benjamin Shine | 1 Oct 05:36 2006

For Review: Change change.cafDwEKO4.txt Summary: Many visual and font fixes to calendar

[This includes and supercedes change.Ud7vlXQzH.txt]


Change change.cafDwEKO4.txt by ben <at> cooper.local /Users/ben/src/svn/openlaszlo/branches/legals/demos on 2006-09-30 20:24:13 PDT


Summary: Many visual and font fixes to calendar


New Features:


Bugs Fixed:


Technical Reviewer: minsky

QA Reviewer: (pending)

Doc Reviewer: (pending)


Documentation:


Release Notes:


Details:

This change makes the startup sequence look right, but less fancy. 

Instead of a load percentage indicator, this just shows a still

image (captured from the swf that had been used for loading) while

the app is loading. This change also tweaks the startup animations 

to be a bit slower so we have a chance of seeing >1 frames of it in

DHTML.


Centralized handling of fonts; instead of specifying fonts in many places all over the app, I specify fonts in the top-level views. We're now using Verdana 10 throughout. Made the buttons use bold fonts, to match old swf look.


Replaced custom vscrollbar with lz/scrollbar. Changed some positioning values from constraints to constant, when they actually would be constants. 


Removed code for rotating arrows in tab-slider, since we just can't support rotation in DHTML. 


Replaced basetabslider with tabslider, because tabslider seems to work; we don't need a custom tabslider.  


Tests:


Files:

M      calendar/cal-button.lzx

M      calendar/calendar.lzx

M      calendar/resources.lzx

M      calendar/infopanel.lzx

M      calendar/day.lzx

M      calendar/loading.lzx

M      calendar/event.lzx

M      calendar/eventselector.lzx

M      calendar/selected-daylook.lzx

A      calendar/images/loading/cal_load_still.png

D      calendar/images/loading/autoPng

D      calendar/images/loading/autoPng/load.png

D      calendar/images/loading/autoPng/cal_load_still.png

M      calendar/basepanel.lzx

M      calendar/textbox.lzx


Attachment (patch.ben.Nhhw.tgz): application/octet-stream, 51 KiB


_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Max Carlson | 1 Oct 05:49 2006

Re: For Review: Change change.C6vFh0Zaf.txt Summary: Port LvViewLinkage to DHTML

.width should give you the correct size if resize==true.

-Max

Benjamin Shine wrote:
> Calendar does a whole bunch of text measurement. For instance in the 
> monthtitle button:
>                 <method event="ontext">
>                     this.setX( Math.round( ( this.parent.width -
>                                this.getTextWidth())/2.0) - 2);
>                     this.setWidth (this.getTextWidth()+2);
>                     this.parent.monthtitleshdw.setWidth 
> (this.getTextWidth()+2);
> 
>                 </method>
> Can this all be replaced with something simpler and faster?
> 
> On Sep 29, 2006, at 4:00 PM, Max Carlson wrote:
> 
>> Comments:
>> * There is no x/yscaling in DHTML...
>>
>> * _x/yscale are flash-specific properties - you probably want to read 
>> it out of the sprite as it'll be undefined here:
>> +    var scale = "_" + xory + "scale";
>>
>> * These should use kernel API calls instead of if ($as2):
>> + if ($as2) {
>> +        if ((a.sprite.__LZmovieClipRef[scale] / 100) != a[scale]) {
>> +          Debug.error("%s != %s", a.sprite.__LZmovieClipRef[scale] / 
>> 100, a[scale]);
>> +        }
>> +      }
>> ..
>> +      if ($as2) {
>> +        if ((a.sprite.__LZmovieClipRef[scale] / 100) != a[scale]) {
>> +          Debug.error("%s != %s", a.sprite.__LZmovieClipRef[scale] / 
>> 100, a[scale]);
>> +        }
>> +      }
>>
>> -Max
>>
>> P T Withington wrote:
>>> Change change.C6vFh0Zaf.txt by ptw <at> tin-woodsman.local 
>>> /Users/ptw/pending-changes/ on 2006-09-29 18:19:09 EDT
>>> Summary: Port LvViewLinkage to DHTML
>>> Bugs Fixed:
>>> LPP-2816 getAttributeRelative inside a constraint doesn't work in dhtml
>>> Technical Reviewer: adam, max (pending)
>>> QA Reviewer: ben (pending)
>>> Doc Reviewer: n/a
>>> Details:
>>>     Library: LzObjects -> LzViewLinkage
>>>     LzSprite, LaszloView: move getLinkage back to View.
>>>     LzViewLinkage: Remove obsolete Object.error.  Put in class
>>>     declaration.  Simplify loop, use portable _*scale rather than
>>>     movieClip.
>>> Tests:
>>>     Test filed with bug works in both swf and dhtml.
>>>     QA reviewer should verify that it fixes the original problem with 
>>> calendar.
>>> Files:
>>> D      kernel/swf/LaszloObjects.as
>>> M      kernel/swf/Library.lzs
>>> M      kernel/swf/LzSprite.as
>>> A  +   views/LzViewLinkage.lzs
>>> M      views/LaszloView.lzs
>>> M      views/Library.lzs
> 
Max Carlson | 1 Oct 05:52 2006

Re: For Review: Change change.b97YH9IaL.txt Summary: Demo easter egg

Commercial?  No way!  We're open source!  Besides, we're note even 
creating a derivation - we're just showing images.  Then again, I'm not 
a lawyer...

-Max

Benjamin Shine wrote:
> 
> I see that you changed it from restricting the search to Creative  
> Commons License 4 to all CC licenses. Licenses 1-3 prohibit  
> commercial use, even with attribution. 5 and 6 require "share alike";  
> I'm not certain whether our use qualifies as share-alike. Is our use  
> commercial? Arguable.
> 
> In any case -- if we're not going to restrict the search by license,  
> we don't even have to include a query arg for license.
> 
> 
> -                    {argname:"license",
> -                        argvalue:"4"},
> 
> +                    // Any Creative-Commons license (all include  
> attribution)
> +                    {argname:"license", argvalue:"1,2,3,4,5,6"},
> 
> 
> On Sep 30, 2006, at 6:06 AM, P T Withington wrote:
> 
>> Change change.b97YH9IaL.txt by ptw <at> tin-woodsman.local /Users/ptw/ 
>> pending-changes/ on 2006-09-30 09:02:36 EDT
>>
>> Summary: Demo easter egg
>>
>> Technical Reviewer: jgrandy (pending)
>> QA Reviewer: ben (pending)
>> Doc Reviewer: n/a
>>
>> Details:
>>     Change sanfrancisco to openlaszlo,ajax.  Tweak search criteria to
>>     be 'more interesting'.
>>
>> Tests:
>>     IWFM
>>
>> Files:
>> M      data/canned_favorites.xml
>> M      classes/search.lzx
>>
>> <patch.ptw.Vbh5.tgz>
> 
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Max Carlson | 1 Oct 05:53 2006

Re: For Review: Change change.b97YH9IaL.txt Summary: Demo easter egg

Yes, Dore alley was certainly 'colorful...' :)

-Max

P T Withington wrote:
> What, are you trying to be a party-pooper?  We already have two  
> buttons that return nifty colors.  The easter egg is previous demo  
> audiences.  Can you spot yourself?  I think that is much more  
> interesting than another parade of nifty colors.  Especially given  
> some of the bits that the San Fran search has turned up at times...
> 
> On 2006-09-30, at 17:01 EDT, Benjamin Shine wrote:
> 
>> Also, not to put too fine a a point on it, the "sanfrancisco" tag
>> returns a variety of images with bright colors and, ahem, stunning
>> vistas. The openlaszlo,ajax tag gives results which are less varied
>> in subject matter and colors. "sanfrancisco" makes a better demo. An
>> easter egg is a good idea, but I would prefer an easter egg that
>> doesn't change the three pre-loaded searches.
>>
>> We could put in a fourth search, or change the third search if a
>> control key is held down.
>>
>> On Sep 30, 2006, at 6:06 AM, P T Withington wrote:
>>
>>> Change change.b97YH9IaL.txt by ptw <at> tin-woodsman.local /Users/ptw/
>>> pending-changes/ on 2006-09-30 09:02:36 EDT
>>>
>>> Summary: Demo easter egg
>>>
>>> Technical Reviewer: jgrandy (pending)
>>> QA Reviewer: ben (pending)
>>> Doc Reviewer: n/a
>>>
>>> Details:
>>>     Change sanfrancisco to openlaszlo,ajax.  Tweak search criteria to
>>>     be 'more interesting'.
>>>
>>> Tests:
>>>     IWFM
>>>
>>> Files:
>>> M      data/canned_favorites.xml
>>> M      classes/search.lzx
>>>
>>> <patch.ptw.Vbh5.tgz>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev <at> openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> 
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Max Carlson | 1 Oct 08:45 2006

Strange issue with in IE

When I try to run this in IE:
<canvas>
     <view id="foo" width="560" height="1" bgcolor="0x394660" 
oninit="Debug.write(this.sprite.__LZdiv)"/>
</canvas>

The view is way too tall - much larger than one pixel.  For some reason 
I can't understand, the clientHeight of the div is 19.  Any ideas anyone?

Regards,
Max Carlson
OpenLaszlo.org
Scott Evans | 1 Oct 09:40 2006

prioritizing runtime image loading

i have an app that really wants to be able to say 
  view1.setSource(xxx) and do it before all the other queued up images load

i figured it wouldn't be too hard to subclass LzView and override 
setSource to use a priority queue.  but when i talked to adam about this, 
he warned me that i was in for trouble chasing edge conditions, 
spurious/duplicate onload/onerror/etc events, and so on.  

i decided to try it anyway.  my priorityView is mostly working but acting 
a little weird.  i get the feeling adam was right, of course. :)

adam also mentioned that the media loader has some built-in priority code 
that isn't publically exposed.  this seems like a reasonable thing to want 
for certain types of apps.  any thoughts on exposing resource-loading 
priorities?  perhaps as an optional second parameter to setSource()?

gse

Gmane