Hi Bob, I highly appreciate your efforts regarding this issue. I have not had the time yet to think more deeply about this. So below you will find only some of my first thoughts.
Bob Hanson wrote: > a) Do you implement callbacks? If so, which ones? Currently I only implemented message callback to allow somehow the monitoring of script commands. > > b) What WOULD you use if you had it available? What currently is missing in Jmol is the possibility to dump the current display state (rendering, visibility, etc.) in order to be able to restart later or maybe with a larger Jmol display from the same state. So this kind of information at least on an atom level (or even better already combined for groups,chains etc. or maybe even as a complete script) could be used to build a 'reload script' and could bypass the need for a signed applet. I could even imagine using this for exporting images,povray etc.(maybe ASCII encoded by Base64 or something similar, to be able get this into a textarea that could be saved with copy and paste by the user). I would like to integrate a sequence/alignment view (like that which my script at "http://www.fli-leibniz.de/cgi-bin/pdb_alignment.pl?CODE=1a2c"; creates) into the Jmol user interface I developed ("http://www.fli-leibniz.de/cgi-bin/3d_mapping.pl?CODE=1a2c";). This would already be possible by using 'pick callback' and 'message callback',. But it would be a lot of work and presumably be quite unreliable. If the interface could recognize any selection change and then ask Jmol for the current selection this would simplify that a lot and make it much more reliable. > > c) What sort of information (exactly) are you looking for? > So I would like to have all information on any atom that is necessary to produce exactly the same display. If possible and suitable the same on a higher level (like group, chain) or even as a complete 'reload script'. I would like to get information on selection changes. I would like to get information on the current selection, also on different levels (like atom, group etc.) if possible and suitable. > d) Is there a particular format that you would like to see, > other than just the current text-stream of messages? > No specific format, it should just be easily and efficiently parseable. > e) Is it important to you that this mechanism be backward > compatible? > No, it must not be backward compatible. > MORE SPECIFC QUESTION: > > 1. There are currently four callbacks: > > animFrameCallback > loadStructCallback > pickCallback > messageCallback > > Each of these fulfills an obvious need. > Should there be more "callback-like" options? > If so, what? > I would rather like to avoid callbacks, but maybe a 'selectionChangeCallback'. Regards, Rolf ------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
