On 2012.07.16. 21:55, Robert Hanson
On Mon, Jul 16, 2012 at 12:47 PM, Gusts Kaksis <email@example.com>
I think that's why I like C language - it's a perfect balance
between readability and power. :)
i.e., you like that for some reason. More power to you, I
No no, the idea is that internet is for sharing, and "bunch of atom
positions and bonds" might be of value to somebody. So this is why I
never restrict a default functionality to anybody. Same method is
used for all those Lightbox image viewers, where you have a
thumbnail which is wrapped within a link that points to original
image - simple left click opens up a lightbox, but right click
allows you to save the image on your computer. It's this thing of
sharing and freedom of information I'm more into. Anyhow, I think
it's one of those things that a developer should decide on his own
I guess in this context that would become something
<a data-script="load "my
Yes it looks more like that, but for loading I've come up
with even better solution:
<a href="my file.xyz" class="jmol-load">my
And I just use the magic of jQuery's selectors to add this:
$('#jmol').jmol('load "' + $(this).attr('href') + '"');
This is the one solution, that gives user an opportunity to
(right click -> save as...) or if it's disabled (default
action of a link click). And you can even insert an image in
between <a> tags so that's a beautiful solution to
<a href="my file.xyz" ...>my file</a>
I would still suggest that no one wants to "get the file" --
the value is not in the file, it's in the script. The file is
just a bunch of atom positions and bonds (maybe; not in this
case). If you have a file reader for xyz files, and you are
interested in this app page, then you need the functionality
of the page, not the file. Looking at the file itself -- just
that -- except in the absolute simplest applications -- is not
valuable. There would be absolutely no reason to have an image
tag within the anchor. Unless you figure on replacing the
Yes, then I'd have to turn of my parser. And you didn't answer my
question about output formatting. So I'll repeat it here:
I'm starting to think, that there should be at least two
clear layers in the API. One for the hard core developers,
for example, just jQuery.Jmol.js, for the ones that wish to
do everything themselves, and the second one should be fully
featured library for seasonal developers or complete
amateurs. Last ones could use data-scriptid in conjunction
with something like Jmol.storeScript('myScript', 'load "some
file.xyz"'), while hardcore guys just go with the
Jmol.bindLoader('.jmol-load') or just simply use jQuery.
Interesting point. So there would be a js that would somehow
include a bit of jQuery, but nothing too sophisticated --
really no callback interpretation then, for example.
I'm more intereseted weather the syntax of hover's 1st parameter
will allways be "atom atom_num x y z"?
And what about those parameters of measurement?
"Angle H #2 - C #1 - H #3 : 109.477165", 3, "measurePicked",
1st - a string representation of a mesurement
2nd - ?
3rd - action name?
4th - the angle as a float, right?
I think it would be easier for a developer if thease values would be
presented in a nice and documented structure, so that they can
create whatever output they wish from it.
Sorry, didn't mean to sound rude. :(
[We don't refer to any of our users as amateurs. Very few are
professional programmers, actually.]
Well, then for very complicated script I see a solution, right in
that spt file. And why not? It's the same as a js file for the
By the way, what is
Jmol spt file? It's Jmol's script file source, what about
the same use case as in my <a href="file.mol"
class="jmol-load">Load my file</a>, just with a
prepared script file <a href="wireframe.spt"
class="jmol-load">Wireframe</a>. It creates a
separate request to the server, but it would really separate
HTML even from Jmol's scripts. One more option to think
An spt file is a script file for Jmol. It runs from the SCRIPT
command rather than the LOAD command. ".spt" there is not
significant; it could have any extension. Jmol does not put
any weight on file extensions except in very few
circumstances. (If you use LOAD with a .spt, .png, .pngj, or
.jmol file, it will switch to SCRIPT and use that instead, but
that's about it.)
Now it works.
In any case, no one
wants to download a pdb file as last resort.
That's way too esoteric. (Anyone who could
read that file will not want it this way.)
If the applet doesn't load, the best
solution is to provide an image. That's what
JmolApplet.js does, upon request.
I'd propose a different approach and throw in one
more buzzword - accessibility :) neither Flash nor
Java is good with all the screen readers for blind
people, but they are not my main concern here. My
approach would be to show a static image in the
placeholder in the first place and then gradually
replace it with Jmol applet (instantly or with a
mouse click). By the way, it's the approach http://www.pdb.org/
are using, which, I must say, is really thought
trough. I think it's called degrading gracefully.
And throwing in an option for file download if
Jmol could not be started is one of them.
Yes, just right now. But it does only draw a static 3D
image, right? Or should it be interactive, like rotation and
zoom? And loading buttons don't do anything on my iPhone.
my bad. I forgot to implement server-side image generation
from databases. Try it now.