On Sep 14, 2005, at 2:06 , Jan wrote:
Timothy Driscoll wrote:
this is an interesting issue. on the one hand, it is useful to be
able to change the underlying colors of a scheme, especially if
you want consistency between different display elements (i.e., to
match a Jmol figures with a textbook figure).
OTOH, one could argue that a color scheme is more powerful if it
remains consistent within itself - in other words, alpha helices
always red, beta strands yellow, turns blue, etc. (this was one
motive for establishing the DRuMS set of schemes, btw.)
This is your private scheme, not suported by me. You may try to use
Jmol to promote it, but I like the freedom to continue using an
alternative one, other programs color stands blue by default (but
this could be altered of corse) e.g. MolMol standard ribbon.mac
DRuMS does not aim to impinge upon your freedom to use a different
scheme. it is nothing more than a standard set of colors. it aims
to increase the usefulness of color as a pedagogical tool, one that
can survive across different software programs and Web sites.
I intended this to be merely an issue for discussion, not a
promotional tool of any kind. I hope that was quite clear from the
way my message was phrased (esp considering DRuMS was merely a
parenthetical 'by the way' comment).
to use Bob's example, to me, CPK has a certain set of colors
associated with it (with carbon as black or dark gray). so if I
saw a
you are right CPK is a color scheme but the scripting language
misuse it to "reset to current scheme" whatever the scheme is
ok.
green sphere in a molecule, I would not immediately associate it
with carbon (chlorine is more like it). if I saw a lot of green
spheres in an obvious protein context, I could certainly reach the
logical conclusion that it is probably not chlorine - but the
associative link between color and element identity would not be
as strong now.
Our carbon source are green plants, if you need a hint ;-) and more
important the contrast of green is much better
my point is not the fitness of any particular color; we could debate
for decades about the best color for carbon (graphite is dark gray;
so is charcoal. and green plants are our oxygen source; should
oxygen be green instead of red? :-).
I am more interested in the underlying concept of associative
learning. if I visit ten different Web sites with ten different
colors for carbon, it dramatically lessens the usefulness of color as
a tool for communicating information about an element's identity.
and everything that is further associated with identity itself, too -
size, charge, bonding, etc. there is a lot of (generally mis- or
unused) power in the visual association between color and concept.
you may argue that having control over color combinations is more
important; at the software level, I agree completely. the user
should have this freedom, no question. I am just saying that the
judicious use of such freedom may reap substantial pedagogical rewards.
NONE is not DEFAULT, it means hereted from ancestor element (in
most cases, this would be the actual atom color). NONE is
indispensable. NONE is part of the RasMolScripting language.
Regards, Jan
I agree; NONE is indispensable. I think it is not quite so
straightforward to determine what should be the 'actual atom
color' though.
This is the color, which is associated with the atom at any moment,
coloring e.g. a label with NONE would make it "transparent" so it
takes the color of the atom as the label color
ok. so you need to know the original scheme applied to the selected
set, plus any change you may have made to that underlying scheme with
regards to the selected set, to know what 'color none' will do.
tim
--
Timothy Driscoll
molvisions - see. grasp. learn.
<http://www.molvisions.com/>
earth:usa:virginia:blacksburg
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
