Those of you who are involved with coding Jmol, please take a look
at this diagram. This is a first draft of an blueprint for cleaning up
and better defining the browser/applet/app interaction.
http://www.stolaf.edu/people/hansonr/jmol/docs/dev/viewer.gif
note:
1) viewer.statusManager delivers content to the app and applet through
their common JmolStatusListener interface. This is a one-way street.
Strictly for writing to the console and notifying the applet/app of
events meriting special attention.
2) viewer.propertyManager accepts calls from the app and applet via the
viewer.getProperty() method and through that can deliver Strings or
other Objects (Hashtables, Vectors, Matrix3f, Point3f, etc.)
3) note that statusManager and propertyManager are one-way streets, in
both cases drawing data from the viewer and transmitting that data
through the main applet or app interfaces to the user.
3) all subclasses of viewer -- viewer.statusManager,
viewer.pickingManager, etc. -- do all their cross-talk via viewer
methods. That is, (far as I know), they always call functions in Viewer
class even though they could each other directly using, say,
viewer.modelManager.getModelInfo().
Miguel, in addition, I thought you might find this pivot table interesting:
http://www.stolaf.edu/people/hansonr/jmol/docs/dev/viewer_refs.xls
-Bob
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
