Egon wrote: > But it sounds now that the viewer is not just a viewer but a data storage > too... which is not that strange since Miguel had to come up with a very > efficient data model...
True [snip] >> How would you suggest I can get a hold of the atomic coordinates and >> all that in the Jmol application? > > So, from the above mind experiment... > > "Saving should be done by extracting info from the adapter and not the > viewer" > > However, I'm not completely sure wether the viewer contains additional > information we might need for saving some certain file formats, like > POV... > > Miguel, what do you think? I think that the data for povray export and for file export needs to come from the Viewer. The Viewer has access to the representation of the atoms and all the shapes (ribbons, trace, etc.) I am continuing to think about the API that will allow effective access to the property/attribute values of the atoms and secondary shape coordinates. Certainly the povray/graphic export options should have access to the current state of the viewer so that they can generate output that is consistent with the current visual representation displayed in the Viewer. Miguel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
