Benjamin Shine | 1 Oct 02:30
Favicon

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
Favicon

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
Favicon

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
Favicon

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
Favicon

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  
(Continue reading)

Max Carlson | 1 Oct 05:49
Favicon

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] / 
(Continue reading)

Max Carlson | 1 Oct 05:52
Favicon

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
(Continue reading)

Max Carlson | 1 Oct 05:53
Favicon

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
>>>
(Continue reading)

Max Carlson | 1 Oct 08:45
Favicon

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
Favicon

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