I have some questions about Jmol features:
Multiple file load
------------------
Nico recently added the capability to load more than one file at a time
and display them concurrently, as different frames/models. The syntax is
load "some-keyword" "filename1" "filename2" ... "filenameN"
For example:
load "myFiles" "caffeine.xyz" "1crn.pdb"
I worked a bit on this yesterday. A demo is at
http://www.stolaf.edu/people/hansonr/jmol/test/json/property.htm
My questions are these:
1) What is the proper behavior of this feature?
2) Is there some use for that first parameter?
3) Should we document it in the next release?
Inline pmesh
------------
I got to thinking about the request for lines, and that got
me thinking about planes, and that got me thinking about pmesh.
The pmesh format nicely allows for simple production of planes.
Yesterday I adjusted it a bit to allow for lines and points and
designed in the capability to enter pmesh data inline on the
pmesh command line thusly:
pmesh test4 "inline" "4 0. 0. 0. 0. 2. 0. 2. 2. 0. 2. 0. 0. 1 5 0 1 2 3
0" <javascript:showscript(8,0)>
Here "inline" substitutes for a filename, and the usual
restriction that there be one integer or three floats per
line is lifted. This particular entry consists of four points and one
mesh, a quadrilateral.
see http://www.stolaf.edu/people/hansonr/jmol/test/json/pmesh.htm
It doesn't really satisfy a general desire for non-molecular annotation
and graphics, but I thought it might be a simple start.
Embedded Scripts
----------------
I hope I haven't done something here that is philosophically inappropriate.
I thought that if one wanted mirror planes, axes, and such, these are
certainly model-dependent, and along the lines of MDL CTFiles
(http://www.mdli.com/downloads/public/ctfile/ctfile.pdf), which embed
3D search query information in the form of points, lines, and planes,
these features might reasonably be embedded in a data file.
Similarly to the (undocumented) #noautobond feature for XYZ files --
in the comment line of XYZ files -- I implemented this
as "#jmolscript:", recognized on the 2nd line of XYZ or MOL files.
see http://www.stolaf.edu/people/hansonr/jmol/test/json/water.xyz
and http://www.stolaf.edu/people/hansonr/jmol/test/json/pmesh.htm
This is why that model comes up with planes already defined, and it
reorients itself.
Questions:
1) Is this a BAD idea?
2) Do people find it potentially useful?
3) Should we implement it in other file types?
File Headers
------------
When the PDB file header is requested, the following command is executed:
String modelFile = viewer.getCurrentFileAsString();
Now, to me this looks rather brute force. The file has already been read.
Questions:
1) Is there another way of doing this that is more efficient?
2) Should we instead be saving the REMARKS section of a PDB file in the
AtomSetCollection property "fileHeader"? Or is that just general waste?
3) In Java is there a simple way of, say, indicating that the header
ends at byte 12025, and then later just pulling in those first bytes
directly? (Like can be done in Visual Basic?)
Viewer.getProperty()
--------------------
Development of this feature is going well. We currently have several
options, including:
appletInfo
fileName
fileHeader
fileContents
fileContents,<pathname>
animationInfo
modelInfo
polymerInfo
structureInfo
boundboxInfo
centerInfo
orientationInfo
transformInfo
zoomInfo
atomList,<atom selection>
atomInfo,<atom selection>
bondInfo,<atom selection>
extractModel,<atom selection>
jmolStatus,statusNameList
jmolViewer
messageQueue
Questions:
1) What's a more efficient way of cataloging these properties?
(Can I have a Hashtable that has as values actual pointers to the functions
to call, and then call them, for example?)
2) What others do we want?
statusManager and getProperty("jmolStatus")
-------------------------
I've implemented several status message types. These include:
atomPicked
fileLoaded
fileLoadError
frameChanged
measureCompleted
measurePending
measurePicked
newOrientation
scriptEcho
scriptError
scriptMessage
scriptStarted
scriptStatus
scriptTerminated
userAction
viewerRefreshed
They are demonstrated at
http://www.stolaf.edu/people/hansonr/jmol/test/json/callback.htm
I don't have time right now to go into them. But I think you will
find that these are far more useful than the old callback options.
The VERY MAJOR downside of this is that it turns out that polling the
applet, even just every 1/2 second, in Firefox results in disfunctional
text entry. (It's not Jmol -- I've reproduced this with a ping/pong applet.)
See http://www.stolaf.edu/people/hansonr/jmol/test/ping
Questions:
1) WHAT TO DO ABOUT THIS FIREFOX ISSUE?
2) Satisfied with this list?
Jmol.js
-------
I'm experimenting with ways to make access to these easier.
You can see what I've done at the end of
http://www.stolaf.edu/people/hansonr/jmol/test/json/Jmol-new.js
Basically, I figure that people should be able to say
MyArray = jmolGetPropertyAsArray("xyz")
MyString = jmolGetPropertyAsString("xyz")
MyString = jmolGetPropertyAsJSON("xyz")
MyObject = jmolGetPropertyAsJavaObject("xyz")
MyArray = jmolGetStatus("whatever")
Questions:
1) Does this sound reasonable?
Thanks,
Bob Hanson
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
