I'm all for ditching colors.lzx.
Lou: Let me know what you're going to change the text in the description
to read, and I'll fix LPP-7194 to look the way the description says it
should. Or, if you want, I can just assign it to you and you can check
in the example with the doc text... Your call.
P T Withington wrote:
Add that to the bug.
Clearly the parser sux.
Also, I discovered that if I say:
bgcolor="${iceblue}"
and iceblue is not defined in lz.colors, I get:
#000ceb
as my color. As in iCEBlue. It's like the parser is trying to find a
hex string in there somewhere, and skipping over any initial non-hex
characters. That seems pretty counter-intuitive to me, it not dead
wrong.
On 2008-11-19, at 11:25EST, Lou Iorio wrote:
Ah, I see: you need to specify 0% as 00%. Curiously, you can have values
over 100%. 1000% looks the same as 100%.
On Nov 19, 2008, at 11:57 AM, Lou Iorio wrote:
Are there restrictions on the values you use for %?
This works:
<view width="50" height="50" bgcolor="rgb(13%,10%,60%)"/>
but this:
<view width="50" height="50" bgcolor="rgb(13%,0%,60%)"/>
gives me this error:
Invalid value for bgcolor on LzSprite for view [50.00 x
50.00]*[1.00 0 0.00, 0 1.00 0.00, 0 0 1]: (void 0)
Ditto, it seems, for any value under 10%.
On Nov 19, 2008, at 11:25 AM, P T Withington wrote:
That seems fine.
You might want to throw in an rbg % example. rgb(97%,89%,59%),
for example, just to cover all the possibilities.
On 2008-11-19, at 10:05EST, Lou Iorio wrote:
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
