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
