please check
http://www.stolaf.edu/people/hansonr/jmol/docs/testdoc.htm?search=color
thanks,
Bob
Miguel wrote:
OK, so after an hour here I'm pretty well convinced the color business
is ultra tricky to describe.
Agreed.
Here is what I see:
color [RGB-color] color [color-scheme] color [colorable-object] [color-or-none] color [shape-token] [color-scheme] color [shape-token] none color hbonds type
We should describe that "name of a color" is one of the 140 colors adopted by the JavaScript/ECMAScript specification. We should find some better references, but here we are for now: http://www.webcolors.freeserve.co.uk/names140.htm
where
[RGB-color] is a name of a color or a color triple, eg [255,0,255] --
(color)
[color-or-none] is a color or "none" -- none, (color)
[color-scheme] is to color based on a scheme -- (color), amino,
chain, cpk, formalcharge, partialcharge, shapely, structure
[colorable-object] is an object that can be colored, but not by a
scheme -- bond, bonds, "dotsConcave", "dotsConvex", "dotsSaddle", label,
hbonds, ssbonds
[shape-token] is one of the following: -- atom, axes, backbone,
bonds, boundbox, cartoon, dots, echo, frank, hover, label, mesh,
monitor, prueba, ribbon, rocket, strands, trace, unitcell, vector
Of course, this will be a growing list.
Now, the logic here seems to be that some objects are colorable by a scheme but some aren't. That makes sense to me when I look at the list of things that cannot be colored by a scheme (bonds, dots, labels, hbonds, ssbonds)--ok--, but when I look at things that can ("shape-tokens") I have trouble. This is coming from the switch in color() in Eval.java:
case Token.atom: case Token.trace: case Token.backbone: case Token.mesh: case Token.strands: case Token.ribbon: case Token.prueba: case Token.cartoon: case Token.rocket: case Token.dots: case Token.axes: case Token.boundbox: case Token.unitcell: case Token.frank: case Token.echo: case Token.monitor: case Token.hover: case Token.vector: colorObject(tok, 2); break;
But colorObject() allows for all the schemes. I recommend breaking this into two sets:
case Token.atom: case Token.trace: case Token.backbone: case Token.mesh: case Token.strands: case Token.ribbon: case Token.prueba: case Token.cartoon: case Token.rocket: case Token.dots: colorObject(tok, 2); break; case Token.axes: case Token.boundbox: case Token.unitcell: case Token.frank: case Token.echo: case Token.monitor: case Token.hover: case Token.vector: (void) getColorParam(2) colorObject(tok, 2); break;
The idea here--I think this does it--is to first check that the color
parameter really is a color--and hitting the exception before going to
colorObject().
OK, that makes sense.
I don't know if the (void) is needed here.
Nope.
If this were
the case, then I would add a new definition--
[snip]
In addition, these same "shape_tokens" (atoms, etc.) are being used in the background() command. In the background() function we have:
viewer.setShapeProperty(getShapeType(tok), "bgcolor", getColorOrNoneParam(2));
But what can really have a background? My guess is that it's only the
label, echo, and hover that can have a background. If that's the case,
then this should be checked in background() prior to this viewer call.
I consider these fonts, colors, and sizes to be 'properties' of the underlying object. Therefore, I don't see anything wrong with making a call to set the 'bgcolor' property on something that doesn't really support it. Seems to me that it is more trouble to do the error checking than to let the code run but take no effect.
If you feel strongly about this then I will reconsider.
In this particular case, it occurs to me that we may want to give Atoms and Bonds a bgcolor property ... implemented as a (transparent?) colored halo that one could use to draw attention to the atoms/bonds.
Miguel
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
-- Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr
------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
