Changes between Version 2 and Version 3 of Notifications

Timestamp:

Jun 19, 2015, 5:00:54 PM (10 years ago)

Author:

Eric Pettersen

Comment:

--

Notifications

@@ -8 +8 @@
 == Graphics Updates
 
-Whereas Chimera 1 has Model::setMajorChange() and Model::setMinorChange(), I'm thinking Chimera 2 will have just have Graph::set_graphics_change() with a default arg of Graph::GC_REBUILD.  Other arguments would be added as needed, but I'm no graphics guru so am not going to propose a complete set, though I'm imagining that Graph::GC_REDRAW might be useful(?).  At any rate, the Python layer would be in charge of querying and clearing the change flags at the appropriate time.
+Whereas Chimera 1 has Model::setMajorChange() and Model::setMinorChange(), I'm thinking Chimera 2 will have just have Graph::set_graphics_change() with a default arg of Graph::GC_REBUILD.  Other arguments would be added as needed, but I'm no graphics guru so am not going to propose a complete set, though I'm imagining that Graph::GC_REDRAW might be useful(?).  At any rate, the Python layer would be in charge of querying and clearing the change flags at the appropriate time.  Depending on what is most useful, turning on a "bigger" flag may also turn on "lesser" flags, e.g. GC_REBUILD also sets GC_REDRAW.  Whatever behavior the "graphics guys" want here really.
+
+There is no Model class in the C++ layer at this point.  If there ever is one then this support would be moved from Graph to that class.
 
 == Data Changes
+
+Again, this will be similar in many ways to Chimera 1.  Changing the color of an Atom will put that Atom in the "modified" set of Atoms and add "color changed" to the list of Atom reasons.  A significant difference from Chimera 1 is that instead of firing individual Atom/Residue/Chain/etc. triggers, one "atomic data" trigger will fire that has keys of Atom/Residue/Chain/etc. and values that contain the reasons, the sets of create/modified atoms, and possibly the set of deleted atoms.  This eliminates timing issues of which trigger should fire first and eliminates the possibility of changes by trigger handlers "infiltrating" later single-class triggers.  Such changes will instead accumulate into the next firing of the atomic-data trigger.