[Laszlo-dev] dguide: Color chapter

[P T Withington]

You are correct, as long as you take the `debug="true"` out of the  
canvas tag.  Then you will notice that the colors are wrong without  
the include.  You can load your example in DHTML with the debugger on  
and see:

WARNING: invalid color string: gold4

But, there is another bug here.  I don't understand why I don't get a  
warning about `iceblue1`, which, rather than displaying as black,  
displays as:

lzx> mystic.presentAttribute('bgcolor', 'color')
'#000ceb'

Which ain't iceblue1:

lzx> Debug.format("#%06d\n", lz.colors.iceblue1)
#3298963

On 2008-11-18, at 06:42EST, Lou Iorio wrote:

> So in this broken example in the dguide (I think Josh is working on  
> it, but
> I want to make sure I understand):
>
> <canvas debug="true">
>    <simplelayout axis="x" spacing="10"/>
>    <class name="box1" width="100" height="100" bgcolor="$ 
> {global['gold4']}"/>
>    <class name="box2" width="100" height="100" bgcolor="${iceblue1}"/>
>    <box1 id="sun">
>        <text text="Sun"/>
>    </box1>
>    <box2 id="mystic">
>        <text fgcolor="0xFFFFFF" text="Mystic"/>
>    </box2>
> </canvas>
>
> You need to change the class tags:
>
>    <class name="box1" width="100" height="100" bgcolor="gold4"/>
>    <class name="box2" width="100" height="100" bgcolor="iceblue1"/>
>
> But this only works because the debugger is on, and that includes  
> the extra colors.
>
> If you turn the debugger off, the example displays the wrong colors.  
> You then need
> to add this:
>
>    <include href="base/colors.lzx"/>
>
> for the example to work.
>
> I don't see a JIRA for this. If I'm correct, I'll file a JIRA and  
> fix the example and
> the paragraph that introduces it.
>
>
> On Nov 16, 2008, at 10:11 AM, P T Withington wrote:
>
>> Probably so.
>>
>> Amusingly, for your little example that we worked on, since it  
>> includes a slider, you get all those colors.  I think if you  
>> include _any_ component, you get all the extra colors, but if you  
>> just try to use one of those extra colors on a plain view, you will  
>> lose (unless you happen to be in debug mode, in which case the  
>> debugger will have included them for you).  Messy.
>>
>> On 2008-11-16, at 07:05EST, Lou Iorio wrote:
>>
>>>
>>> On Nov 15, 2008, at 6:52 PM, P T Withington wrote:
>>>
>>>> If you load base/colors.lzx, it defines a whole bunch of colors  
>>>> (adds them to lz.colors).  Once that is loaded, you can, in fact,  
>>>> specify colors using those names.
>>>
>>> Ah, thanks, I didn't know that. Perhaps I should add that to the  
>>> dguide?
>>>>
>>>>
>>>> André has pointed out that when you turn debugging on in swf8 or  
>>>> 9, the debugger gets loaded into your app, and it happens to load  
>>>> these extra colors.  So, by accident, you can use these colors in  
>>>> debug mode in swf8/9 (this is one of the many problems with  
>>>> running the debugger in the app, which is why I did not do it  
>>>> that way for dhtml, and why we have the 'console remote debug'  
>>>> option for swf8/9.  If you run the demo app in either dhtml or  
>>>> with the console debugger, you will see only the standard CSS  
>>>> color names.
>>>>
>>>> The upshot is, if you want a demo that uses these extended color  
>>>> names, you need to make your demo include the base/colors.lzx file.
>>>>
>>>> As to the names of the colors in that file, I believe they are  
>>>> psuedo-standard, they might be from emacs, who knows.  I did not  
>>>> create that file.
>>>>
>>>> On 2008-11-15, at 04:48EST, Lou Iorio wrote:
>>>>
>>>>> I concede to your technical prowess. But I still contend that  
>>>>> what I was looking for here is the hex value.
>>>>> I can't use "gray20" to specify a color in lzx, right? I'm a bit  
>>>>> leery of "psuedo-standards".
>>>>>
>>>>> In addition, why is there no red20, green20 or blue20?
>>>>>
>>>>> I'm not suggesting that you change anything, and I'm not trying  
>>>>> to be difficult, I'm just curious.
>>>>>
>>>>>
>>>>> On Nov 14, 2008, at 7:33 PM, P T Withington wrote:
>>>>>
>>>>>> Uh, because 20% gray has a technical meaning:  
>>>>>> rgb(256*(1-20/100),256*(1-20/100),256*(1-20/100)) or  
>>>>>> lab(1-20/100,0,0), or hsb(0,0,20), or #333333, etc., but it  
>>>>>> much shorter to think/say when you want a gray with a certain  
>>>>>> brightness.
>>>>>>
>>>>>> On 2008-11-14, at 18:06EST, Lou Iorio wrote:
>>>>>>
>>>>>>> Sure, but what do I care what someone chose to define as 20%  
>>>>>>> gray? What does that even mean?
>>>>>>> 20% gray, and 80% what else? Any color where the r, g, and b  
>>>>>>> values are the same is gray. Why pick
>>>>>>> an integer percent and name it?
>>>>>>>
>>>>>>> As I said, I'm old; I still think in hex. (And, I still call  
>>>>>>> it 'grey'.)
>>>>>>>
>>>>>>> On Nov 14, 2008, at 6:49 PM, P T Withington wrote:
>>>>>>>
>>>>>>>> Well, as I said in my TODO, there needs to be a way, for a  
>>>>>>>> type like color, for you to say what your preferred  
>>>>>>>> presentation is.  Like maybe you should be allowed to say  
>>>>>>>> something like 'color(rgb)' or 'color(#)' or 'color(token,#)'  
>>>>>>>> or something...  We could get really carried away!
>>>>>>>>
>>>>>>>> I'm pretty sure gray20 is '20% gray' and a psuedo-standard  
>>>>>>>> color name.
>>>>>>>>
>>>>>>>> On 2008-11-14, at 17:38EST, Lou Iorio wrote:
>>>>>>>>
>>>>>>>>> I also noticed several "gray" colors showing up. Cute, but  
>>>>>>>>> I'm not sure I like it.
>>>>>>>>>
>>>>>>>>> gray 20, for example, seems completely arbitrary. For me, I  
>>>>>>>>> really want to see
>>>>>>>>> the hex values. But then, I'm old.
>>>>>>>>>
>>>>>>>>> On Nov 14, 2008, at 6:31 PM, P T Withington wrote:
>>>>>>>>>
>>>>>>>>>> 'data' is historical, because that was the original  
>>>>>>>>>> application for setting/getting string versions of a value,  
>>>>>>>>>> but now we see there are more general reasons to do that.
>>>>>>>>>>
>>>>>>>>>> Isn't it cute how 0 becomes 'black' and 0xffffff becomes  
>>>>>>>>>> 'white'?  If you are very careful, you can set the slider  
>>>>>>>>>> to some other named colors...
>>>>>>>>>>
>>>>>>>>>> Gee, it would be fun to have a 'digital' slider that only  
>>>>>>>>>> let you pick named colors.  Hm...
>>>>>>>>>>
>>>>>>>>>> On 2008-11-14, at 17:10EST, Lou Iorio wrote:
>>>>>>>>>>
>>>>>>>>>>> I like it mucho. The example works just as I intended.
>>>>>>>>>>>
>>>>>>>>>>> From a purely subjective point of view, I like 'present'  
>>>>>>>>>>> and 'accept'.
>>>>>>>>>>>
>>>>>>>>>>> The "Data" part seems extraneous.
>>>>>>>>>>>
>>>>>>>>>>> Lou
>>>>>>>>>>>
>>>>>>>>>>> On Nov 14, 2008, at 5:43 PM, P T Withington wrote:
>>>>>>>>>>>
>>>>>>>>>>>> My fixes are in.  Update, rebuild and try this and see if  
>>>>>>>>>>>> you like it:
>>>>>>>>>>>>
>>>>>>>>>>>> <canvas>
>>>>>>>>>>>> <simplelayout spacing="5"/>
>>>>>>>>>>>> <view id="swatch" width="300" height="100" bgcolor="$ 
>>>>>>>>>>>> {color.value}" />
>>>>>>>>>>>> <view id="sliders">
>>>>>>>>>>>> <simplelayout />
>>>>>>>>>>>> <slider id="color" width="300" value="0" minvalue="0"  
>>>>>>>>>>>> maxvalue="0xffffff" type="color" />
>>>>>>>>>>>> <text text="${color.updateData()}" />
>>>>>>>>>>>> </view>
>>>>>>>>>>>> </canvas>
>>>>>>>>>>>>
>>>>>>>>>>>> `updateData` is probably not the most mnemonic name for  
>>>>>>>>>>>> how to get a string representation of the slider's value  
>>>>>>>>>>>> according to the type (in this case 'color').  The  
>>>>>>>>>>>> inverse is called `applyData`, it takes a string  
>>>>>>>>>>>> representation and tries to parse it according to the  
>>>>>>>>>>>> type. `presentValueAsString` / `acceptValueFromString`  
>>>>>>>>>>>> seem too ponderous.  Perhaps simply `present` and  
>>>>>>>>>>>> `accept`?  I'd appreciate your input.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2008-11-14, at 09:42EST, Lou Iorio wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 13, 2008, at 1:17 PM, P T Withington wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Basically, using '0x000000' in CSS was a kludge, non- 
>>>>>>>>>>>>>> standard, and probably should have been documented as  
>>>>>>>>>>>>>> such.  It will cause a deprecation warning.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any of the other 3 methods are standard, acceptable,  
>>>>>>>>>>>>>> and work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would be fine with me if we just said that you  
>>>>>>>>>>>>>> specified colors the same as the CSS standard.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You can specify your color as a numeric value also, the  
>>>>>>>>>>>>>> result of a computation, it doesn't need to be  
>>>>>>>>>>>>>> expressed as a hex constant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll add this to the chapter. I'd like to include a  
>>>>>>>>>>>>> simple example:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>>>> <canvas>
>>>>>>>>>>>>> <simplelayout spacing="5"/>
>>>>>>>>>>>>> <view id="swatch" width="300" height="100" bgcolor="$ 
>>>>>>>>>>>>> {color.value}" />
>>>>>>>>>>>>> <view id="sliders">
>>>>>>>>>>>>> <simplelayout />
>>>>>>>>>>>>> <slider id="color" width="300" value="0" minvalue="0"  
>>>>>>>>>>>>> maxvalue="16777215"/>
>>>>>>>>>>>>> <text text="${color.value}" />
>>>>>>>>>>>>> </view>
>>>>>>>>>>>>> </canvas>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is this worth including? My intent for the last <text>  
>>>>>>>>>>>>> tag was to print the hex equivalent
>>>>>>>>>>>>> of the slider value, but I can't figure out how to do  
>>>>>>>>>>>>> that. I tried:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <text text="${color.value.toString(16)}" />
>>>>>>>>>>>>>
>>>>>>>>>>>>> but that doesn't work. Any ideas? Better example?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lou
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2008-11-13, at 08:49EST, Lou Iorio wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The text preceding Example 20.3. Coloring text using  
>>>>>>>>>>>>>>> CSS seems to completely contradict what the example  
>>>>>>>>>>>>>>> shows.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The text says:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OpenLaszlo enables coloring in four ways: 0x000000,  
>>>>>>>>>>>>>>> #000000, rgb(0,0,0), and "black". For now, the best  
>>>>>>>>>>>>>>> reason to prefer to use the hex style 0x000000 is that  
>>>>>>>>>>>>>>> it always works, whether the color is assigned  
>>>>>>>>>>>>>>> explicitly within the view, or by stylesheet. Color  
>>>>>>>>>>>>>>> assignment by stylesheet fails by name, #hex, or  
>>>>>>>>>>>>>>> rgb(). Explicit color assignment by rgb() fails unless  
>>>>>>>>>>>>>>> the RGB values are all numerals -- that is, rgb(0,0,0)  
>>>>>>>>>>>>>>> produces black, but rgb(FF,FF,FF), which should  
>>>>>>>>>>>>>>> produce white, comes back at compile time as an  
>>>>>>>>>>>>>>> invalid color.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Coloring of text with fgcolor="foo" is enabled in the  
>>>>>>>>>>>>>>> same fashions, but with the same limitations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> CSS spits out an error if you use 0x000000. How about:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OpenLaszlo enables coloring in four ways: 0x000000,  
>>>>>>>>>>>>>>> #000000, rgb(0,0,0), and "black". Using the format  
>>>>>>>>>>>>>>> 0x000000 only works for explicit assignment; it does  
>>>>>>>>>>>>>>> not work in CSS. Color assignment using rgb() must be  
>>>>>>>>>>>>>>> specified with decimal values from 0 - 255.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Coloring of text with fgcolor="foo" is enabled in the  
>>>>>>>>>>>>>>> same fashions, but with the same limitations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In addition, the title of the example, "Coloring text  
>>>>>>>>>>>>>>> using CSS", might be better if changed to "Applying  
>>>>>>>>>>>>>>> color explictly and with CSS" since it shows coloring  
>>>>>>>>>>>>>>> views as well as text.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you agree (or have a better idea), I'll make the  
>>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lou
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>