Bob Hanson wrote:
Jan wrote:
I don't see a difference whether I say
monitor 2087 2088
or
monitor ([LIP]3:A.O5) ([LIP]3:A.O6)
Oh, sure. OK. I don't know that we are headed that way wth the monitor
command, because there are some programming issues with putting two
atom expressions in the same command -- nothing really insurmountable,
really, but not exactly trivial.
I thought you were talking about, say, specifying four atoms and then
somehow Jmol was to decide what arrangement you wanted for a dihedral.
THAT seems prone to problems.
But I don't see why we couldn't have:
getProperty("getDistance", "[LIP]3:A.O5", "[LIP]3:A.O6")
Mostly I don't like special cases. So the challenge would be to make
this extensible to
getProperty("getAngle", "[LIP]3:A.O5","[LIP]3:A.O6","[LIP]3:A.O7")
we already have
monitor 111 112 113
why not
getProperty("measure","[LIP]3:A.O5","[LIP]3:A.O6","[LIP]3:A.O7")
no additional keyword has to be remembered
... some seconds later ...
this is not necessary, something like
getProperty('monitor ' + getPorperty('select
[LIP]3:A.O5').atomInfo[0].atomno + ' ' + ...
would do it until the script parser itself managed to parse multiple
select expressions (or Jmol.js)
getProperty("getTorsionAngle",
"[LIP]3:A.O5","[LIP]3:A.O6","[LIP]3:A.O7","[LIP]3:A.O8")
Anyway -- these would be in the category "not a callback," I think.
But it's a great idea, and one that we'll definitely implement somehow.
I'm assuming for this idea:
1) You don't want to (necessarily) display the monitor line w/ or w/o
numbers
agreed
2) You want to be able to display the monitor line w/ or w/o numbers
(do that separately, with a script command, but that command format
could be returned as one of the elements of the data structure).
yes
3) All three -- getDistance, getAngle, getTorsionAngle -- should be
available. Maybe a simple "getPosition" as well, just to head off the
obvious request.
Yes, I could imagine this to be very useful.
Yes, this would be comfortable, it saves me from using
atomInfo[0].x atomInfo[0].y atomInfo[0].z
By the way, Jmol caches up to 16 measurements. (Something the applet
has never
had an interface to.) That is, you can make up to 16 measurements by
clicking the
mouse, and they are all saved automatically. The Jmol application
utilizes this for its table; there's no reason not to expose it as a
JSON structure to the web page.
a monitoring function on your callback.htm
monitor: measurementsChange
works for me, but I miss the corresponding e.g. "monitor 1 2 3" command
which would be much more readable if 1 2 3 where atomInfo[0].info strings
monitor:measureSelection
didn't work?
The distinction I think I want to make here is the .script() method
used solely/primarily for driving the display; the .getProperty()
method for retrieving information. We can talk about .setProperty() or
.scriptSynchronous() later....
callback would only be luxurious for Jmol console use and especially
with a console only mode, if a Jmol --nodisply batch run option would
get implemented like in RasMol, if the applet is used, JavaScript is
already involved and there is no need for callback via JmolScript,
getProperty() is superior, callback is only used for functional
compatibility with RasMol scripts.
callbacks don't have any relation to the console -- those are just
messages. The function of callbacks -- or their replacement with
getProperty("callbackStatus","...") -- is to deliver timely
information about user activity. When there is no user, there is no
issue with callbacks, I think.
I use callbacks in RasMol to query e.g. which amino acids are in 3.2 A
distance to a hetero component
(echo "load pdb inline\nselect within(3.2, [LIP]3) and not [LIP]3\nshow
selected group\nexit\n";cut 1imb.pdb) | rasmol -nodisplay |
evaluateMakeRasMolScriptFromIt.pl | rasmol
without any user, the startup JmolScript could replace the interacting
user, that is the main use for messageCallback
RasMol>show selected group
should result in a select expression
Hmm. That's an interesting idea. How does it choose the "right"
select expression? But I see what you are
after -- so that you can save that and recall that particular
selection. This could be tricky....
The right is *a* short expression, if 16/16 atoms of a group are
selected, no doubt, no individual atom should be selected. There is
no need for the shortest, but a symbolic human readable expression is
preferred over *only* an ordered atom number list (needed for compare
operations).
e.g.
>=1 model? <model expression>
>=1 chain? <chain expression>
>=1 group? <group expression>
>0.5 group? <group expression> and not ( <atom expression> )
>4 atoms? <group expression> and ( <atom expression> )
backbone? <group expression> and backbone
: <atom expression>
This would be a major challenge, I think. But at least you can do
getProperty("atomInfo","(atom selection)"))
so if you like that, maybe that's all we need for now. At least with
that you get the individual atom list.
I agree, all is there, but at some places, it could be a bit more
comfortable for end users.
Regards, Jan
-------------------------------------------------------
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
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
