[Laszlo-dev] dguide: Color chapter

Lou Iorio lou at louiorio.com
Wed Nov 19 07:05:53 PST 2008


How about if I replace this section with this:

To specify any color other than the 16 which are usable by name, use  
hex codes or rgb().

<canvas height="150">
   <simplelayout axis="y"/>
   <text>using hex values</text>
   <view>
     <simplelayout axis="x"/>
     <view width="50" height="50" bgcolor="#220099"/>
     <view width="50" height="50" bgcolor="#770011"/>
     <view width="50" height="50" bgcolor="#0022ff"/>
     <view width="50" height="50" bgcolor="#ff2200"/>
     <view width="50" height="50" bgcolor="#00ff22"/>
   </view>
   <text>same thing using rgb()</text>
   <view>
     <simplelayout axis="x"/>
     <view width="50" height="50" bgcolor="rgb(34,0,153)"/>
     <view width="50" height="50" bgcolor="rgb(119,0,17)"/>
     <view width="50" height="50" bgcolor="rgb(0,34,255)"/>
     <view width="50" height="50" bgcolor="rgb(255,34,0)"/>
     <view width="50" height="50" bgcolor="rgb(0,255,34)"/>
   </view>
</canvas>

On Nov 19, 2008, at 9:52 AM, P T Withington wrote:

> Yes, let's stop using these non-standard names.  Let's not advertise  
> them.  If you want a 'custom' color, you should specify it with hex  
> or rgb.  I am told that is what our designers do.
>
> I plan to remove colors.lzx, it is a pile of crap.  If you look at  
> it, you will see that it has only a few names, which are names from  
> the X11 standard, but the names are assigned to colors that are  
> _not_ what the X11 standard uses!  I really think this was just  
> pulled from thin air as a demo and does not deserve to be enshrined  
> in our doc or system.
>
> If we want to use named colors, we out to use the standard names and  
> values, not make up something random.
>
> Since I plan to fix lpp-7365 by deleting colors.lzx, you would do me  
> a favor if you deleted any examples based on it.
>
>
> On 2008-11-19, at 08:00EST, Lou Iorio wrote:
>
>> Since this example is about using nonstandard colors, using the  
>> standard colors
>> "yellow" and "aqua" does not make much sense.
>>
>> Should we just drop the entire section "Non-Standard Colors", or  
>> confine it to mentioning hex
>> values only? From my (perhaps naive) view, hex is the best way to  
>> specify color, standard or
>> otherwise. "iceblue" looks blue to me, but nothing like ice.
>>
>> On Nov 18, 2008, at 3:43 PM, P T Withington wrote:
>>
>>> See my comment on the bug you just filed.
>>>
>>> Lets stop using the non-standard names from base/colors.lzx  
>>> altogether.  They are bogus.  For this example, how about just  
>>> using `yellow` and `aqua`.
>>>
>>> Sorry this is such a mess.
>>>
>>> On 2008-11-18, at 14:31EST, J Crowley wrote:
>>>
>>>> Hrmm, including base/colors.lzx doesn't get this to work in  
>>>> DHTML.  I filed a bug on this, but Andre said (in http://www.openlaszlo.org/pipermail/laszlo-dev/2008-November/018145.html 
>>>>  ) it could be fixed by including base/colors.lzx, but that  
>>>> doesn't seem to work...  Any ideas?
>>>>
>>>> P T Withington wrote:
>>>>> I appended our email as a comment.
>>>>>
>>>>> On 2008-11-18, at 12:33EST, Lou Iorio wrote:
>>>>>
>>>>>> I see there is a JIRA for this and Josh owns it.
>>>>>>
>>>>>> http://www.openlaszlo.org/jira/browse/LPP-7194
>>>>>>
>>>>>>
>>>>>> On Nov 18, 2008, at 7:42 AM, 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
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>




More information about the Laszlo-dev mailing list