> 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
