Changes between Version 7 and Version 8 of Feb2015MolGraphics

Timestamp:

Jan 9, 2015, 11:49:59 AM (11 years ago)

Author:

Tom Goddard

Comment:

--

Feb2015MolGraphics

@@ -16 +16 @@
 {{{
  display (true/false)
- color
+ color (rgba 8-bit)
 }}}
 
@@ -22 +22 @@
 {{{
  display (true/false)
- radius
- color
+ radius (float)
+ color (rgba 8-bit)
  halfbond (color each half of bond to match near atom)
 }}}
@@ -46 +46 @@
 {{{
  display (true/false)
- color
 }}}
 
@@ -60 +59 @@
 2. No wire and dot mode.
 
-3. Should color objects be immutable?  Chimera 1 allows redefining a color and having all graphics objects using that color automatically update.  Complex code.
+3. Colors are immutable and are 8-bit RGBA, and there is no color hierarchy.
 
-4. How to handle different materials in addition to colors?
+== Immutable Colors ==
 
-5. Keep color hierarchy (model->atom, model->ribbon)?  What about surface colors?
+Proposal: Colors should be immutable 
+
+Here's what immutable colors means.  In Chimera 1 you can assign all oxygen atoms to the same color object (red), then change that color object's red,green,blue values (to say pink) causing all the oxygens to change color.  Immutable colors means you can't change a color's definition.  If you want to change the color of oxygen atoms, you assign a new color to every oxygen atom.  This avoids complicating the C++ code.  Currently the most common Chimera crash (reported about 40 times) seems to be a color reference counting problem to handle the mutable colors.  Also I think users and potential tool writers will be more confused by mutable colors than immutable ones, and mutable ones are rarely useful.
+
+== Color Hierarchy ==
+
+Proposal: No color hierarchy.
+
+Here's what no color hierarchy means.  In Chimera 1 an Atom can have color None, and then it is shown in the Molecule color.  I think Atoms should always have a color (not None). There are advantages and disadvantages to the color hierarchy.  An advantage is "het coloring" where you color oxygens red, nitrogens blue, and carbons follow the molecule color, say tan (carbon atom color is None). Then if you change the molecule color using the color well in the Model Panel just the carbons change to the new color.  A disadvantage is that if you color the atoms in any other way, for example "rainbow chain", then the Model Panel perplexingly shows the molecule color as tan.  What does the user make of this?  Then if they change the Model Panel color well to any other color it has no effect on the rainbow coloring.  So the main disadvantage I see is that users don't understand the color hierarchy, it is not obvious.  It sometimes helps them, and sometimes trips them up.
+
+How would the "no color hierarchy" handle "het coloring".  When you open a molecule in Chimera 2 you would still get smart display with a unique color for the carbons to distinguish it from already open molecules, and red/blue for oxygen/nitrogen.  How could you just change the carbon colors now?  Menu color pink, then menu color het.  Or color command "color @C pink".  Or click the model panel color well and it will show a color dialog that has a "Carbons" switch and it will just change carbon color.  I like keeping the color well in Model panel.  It's main use I think is not changing colors but simply finding which model is the orange one.  Being able to change the color is a bonus.  The trouble with this role is that very often molecules are multi-color (less often with density maps), so no single color represents the model.  I think if you did "rainbow" on a molecule the Model Panel color well should show multicolor.  But probably it should show the colors of just carbons to get the nice benefits of het coloring.  For density maps it will show multicolor if a map is not a single color.  This will make immediate intuitive sense to the user.