Notifications Architecture Proposal

Overview

In broad strokes, the notification system from C++ to Python will be similar to what exists in Chimera 1. There will be two main systems of notifications, one for communicating whether the graphics need updating, and one for communicating data changes to interested code. Neither is synchronous; the Python layer is in charge of when the notifications are acted on.

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. 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.