Site Status: (08/18)
  

Email Archive: jmol-developers (read-only)

What follows is an exerpt from Bob Hanson's first email message to Jmol-developers.

From: Bob Hanson <hansonr@st...>
in-line data?  
2004-05-18 08:48
Does/will the jmol applet have the capability to introduce data in-line? My reason for this is that then as a JavaScript programmer, I could create structures on the the fly right at the client without reference to a fixed server-based file. I think Chime-Pro can do this, but not Chime. Thank you Bob Hanson
 For example, something like:
 
 <parame name=moldata value="
 
 
 
   6  5
     0.0000    0.0000    0.0000 S            
     0.0000    0.0000    1.3400 H            
     0.0000    1.3400    0.0000 H            
     0.0000   -1.3400    0.0000 H            
     1.3400    0.0000    0.0000 H            
    -1.3400    0.0000    0.0000 H            
   1  6  1
   1  5  1
   1  4  1
   1  3  1
   1  2  1
 M  END
 ">
 
 
 
 
 -- 
 
 -- Robert M. Hanson, hansonr@st..., 507-646-3107 
 Professor of Chemistry, St. Olaf College 
 1520 St. Olaf Ave., Northfield, MN 55057 
 mailto:hansonr@st... 
 http://www.stolaf.edu/people/hansonr 
 

 

Thread View

Thread Author Date
in-line data? Bob Hanson <hansonr@st...> 2004-05-18 08:48
By: -
Re: in-line data?  
2004-05-18 09:05
First, the bad news.What you have written *should* work, but it does not ... for reasons that are beyond our control. It turns out that newline characters get stripped from param valuestrings. This is according to the HTML/w3c spec. If I recall correctly,they do not get replace with spaces, they just get removed. So, by thetime we get this string, it has all been put onto one line.Interestingly, this means that we can read CML/XML (Chemical MarkupLanguage) files just fine ... because white space and newline charactersdo not matter. But for all the other file formats, we are dead.People can write scripts on multiple lines ... but each line of the scriptmust be terminated by ";" characters. Again because the newlines will beremoved. The good news is, I have been thinking about another solution to this problem. And I think I have something that will work well. But I need to talk/work with someone on it. It is not a lot of coding work, but I don"t want to implement it until I can talk to a JavaScript/HTML programmer who is going to use it. Did I just hear you volunteer? :-)Miguel

By: -
Re: in-line data?  
2004-05-18 09:52
Line endings are not an issue. In JavaScript I can produce the tag based on any convention you like. Certainly semicolons look good to me for line endings. Yes, I"m certainly volunteering. This is the first I"ve looked at jmol, but I"m fairly impressed already. I"ve done extensive work with Chime, essentially all of it in an "on-the-fly" mode, where frames are filled with structures based on user input. But I"ve been frustrated that even with that I have to be referencing static files. I would be delighted to at least work out a simple sample page that would at least demonstrate some of these capabilities. For more information about my background, see http://www.stolaf.edu/people/hansonrA couple of years ago I looked into creating a plug-in with LiveConnect functionality, but that was right when Netscape dropped LiveConnect (Netscape 6?), so I didn"t follow up on that. I"ve also played around a bit with Java and applets, but that"s not my forte at all. Also extremely useful would be the capability for JavaScript to read the data for a currently displayed file using scripting. For example,
A=new Array()
A=jmolapplet.getAtomCoordinates()

or

XYZ=new Array()
XYZ=jmolapplet.getAtomCoordinates(3)

or setting them:

jmolapplet.setAtomCoordinates(3,XYZ)

or all at once:

jmolapplet.setAtomCoordinates(A)
Is there information somewhere regarding the interactions possible between jmol and JavaScript commands? Bob Hanson

By: -
Re: in-line data?  
2004-05-30 19:40
[clip]
Bob, A general JavaScript mechanism for retrieving information about atom properties does not currently exist. One can send script commands to control atom properties. And one can receive limited information about changes in state through the Chime-compatible callback functions. I think we all agree that a broader, more flexible mechanism is needed. However, there are no plans to introduce this type of functionality as part of Jmol v10. It will need to wait for a later release. I believe that the soonest we could begin serious work in this area will be late 2004.Miguel

By: -
Re: in-line data?  
2004-05-31 06:41
Thanks, Miguel. OK. So is there any information available (source code if nec.) that lists what all of the publicly scriptable functions are of jmol and what all the callbacks return? Bob

By: -
Re: in-line data?  
2004-05-18 11:30
[clip]
Bob wrote:> Line endings are not an issue. In JavaScript I can produce the > > tag based on any convention you like. Certainly semicolons look good to> me for line endings.One would think that it would work to put semicolons at the end of thelines ... but it turns out that there are problems :-(The HTML 4.01 spec says the following:--------http://www.w3.org/TR/html4/types.html#type-cdataCDATA is a sequence of characters from the document character set and mayinclude character entities. User agents should interpret attribute valuesas follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space.--------The fact that carriage returns get replace with spaces, and line feeds get*ignored* means that the final value one gets depends upon whether thefile was edited with a Win32 editor.Win32 systems use carriage return + linefeed. This means that if one putsa semicolon at the end of the line, it will get turned into a semicolon +a space.Unix systems use only a linefeed. So a semicolon + linefeed will turn intoa semicolon.Therefore, we cannot put the semicolon at the end of the line.I think it would work if we put it at the beginning of the line. Theeffect on Win32 files would be that there was an extra space added at theend of the previous line. I do not think that would generally be a problemwith molecular model files. So, I was thinking of the vertical bar character "|" at the *beginning* ofa line to separate lines. Q: Would it work for you to put "|" characters at the beginning of each line? Personally, I don"t like it. So I have tried to come up with another solution. I am thinking of this as an alternate mechanism for "inline" molecular models. Here is what I am thinking ... we do not store the molecular model in the parameter string value. Rather, we store the moleculare model inside the HTML file itself ... with some tag that identifies it as the molecular model. The applet reads its own HTML file and pulls out the molecular model. The rough idea would be something like this:[applet code="JmolApplet" ...] [param name="inline" value="my_molecular_model" /][/applet]I still need to think through the details of how this would be done.It would probably work fine for .html files and pull the .html file fromthe local cache.It would probably have problems on pages that are generated by cgi"sbecause the applet would probably fetch the page again from the webserver.After writing this down ... I don"t like the idea as much as I used to :-(Q: thoughts/comments?> Yes, I"m certainly volunteering.[snip]> I would be delighted to> at least work out a simple sample page that would at least demonstrate> some of these capabilities.Get a rough draft of a page ready.[snip]> I"ve also played around a> bit with Java and applets, but that"s not my forte at all.It will be very helpful for me to have a JavaScript user.> Also extremely useful would be the capability for JavaScript to read the> data for a currently displayed file using scripting. For example,
> > A=new Array()> A=jmolapplet.getAtomCoordinates()
> > or
> > XYZ=new Array()> XYZ=jmolapplet.getAtomCoordinates(3)
> > or setting them:
> > jmolapplet.setAtomCoordinates(3,XYZ)
> > or all at once:
> > jmolapplet.setAtomCoordinates(A)
> > Is there information somewhere regarding the interactions possible> between jmol and JavaScript commands?Your suggestions are good.Currently, you should assume that the only thing you can do is run the document.jmol.script("some RasMol/Chime script")In addition, the Chime callback functions are available.The whole area of LiveConnect communciations between JavaScript and Javaapplets is a swamp that is murky, ugly, and buggy.That is why I need people to work on it from the JavaScript side.My hope/plan is to define a relatively clean interface that will allowJavaScript to query the status of the display. This would be a JavaBeanAPI that would also be available to JavaScript ... that would allow one toinquire about the state of Jmol, including properties of the atoms.Miguel

By: -
Re: in-line data?  
2004-05-18 12:56
Miguel,Vertical bars are great. No problem there.... In fact, that"s precisely what I use in many web-based applications because | is a natural separator. Beginning of the line, end of the line--makes no matter to me. Probably looks nicer at the beginning of the line anyway.I would much prefer it all be part of the parameters. You will run into exactly the same issue with line feeds if it is HTML, and that really (in my mind, anyway) runs contrary to the data/delivery separation idea. Also, it associates the data with the parameters in a clear fashion. If these two are separated, you will also need tags and some sort of parameter that points to the data block by name, as there could easily be a dozen instances of the applet and a dozen data sets on a page (in principle). From a reader"s point of view, it will make far more sense to have all the information together, and from a programmatic point of view, scanning HTML text for data seems to me to be inelegant and possibly error-prone.Bob

By: -
Re: in-line data?  
2004-05-18 13:22
Bob wrote:> Vertical bars are great. No problem there.... In fact, that"s precisely> what I use in many web-based applications because | is a natural> separator. Beginning of the line, end of the line--makes no matter to> me. Probably looks nicer at the beginning of the line anyway. Good ... I just finished implementing this and checking it in :-) The format is: The first vertical bar and any white space before it is ignored.I will send you a separate email with the JmolApplet.jar as an attachment.> I would much prefer it all be part of the parameters. You will run into> exactly the same issue with line feeds if it is HTML, and that really> (in my mind, anyway) runs contrary to the data/delivery separation idea.> Also, it associates the data with the parameters in a clear fashion. If> these two are separated, you will also need tags and some sort of> parameter that points to the data block by name, as there could easily> be a dozen instances of the applet and a dozen data sets on a page (in> principle). From a reader"s point of view, it will make far more sense> to have all the information together, and from a programmatic point of> view, scanning HTML text for data seems to me to be inelegant and> possibly error-prone. All good arguments ... we will hold off on this :-)Miguel

By: -
Re: in-line data?  
2004-05-18 16:23
Incredible. Yes, that worked. I"ll write an application tonight that utilizes this in an interesting way. Miguel, please explain to me, a newcomer to the jmol business, how it is being developed. Are there many people with their own version of this as open code, of which you are one, or are you the creator and maintainer of the "official" jmol code?Bob HansonMiguel wrote:> Bob wrote:>
> >Vertical bars are great. No problem there.... In fact, that"s precisely
> >what I use in many web-based applications because | is a natural
> >separator. Beginning of the line, end of the line--makes no matter to
> >me. Probably looks nicer at the beginning of the line anyway.> > > Good ... I just finished implementing this and checking it in :-)> > The format is:> > > > The first vertical bar and any white space before it is ignored.> > I will send you a separate email with the JmolApplet.jar as an attachment.> > >
> >I would much prefer it all be part of the parameters. You will run into
> >exactly the same issue with line feeds if it is HTML, and that really
> >(in my mind, anyway) runs contrary to the data/delivery separation idea.
> >Also, it associates the data with the parameters in a clear fashion. If
> >these two are separated, you will also need tags and some sort of
> >parameter that points to the data block by name, as there could easily
> >be a dozen instances of the applet and a dozen data sets on a page (in
> >principle). From a reader"s point of view, it will make far more sense
> >to have all the information together, and from a programmatic point of
> >view, scanning HTML text for data seems to me to be inelegant and
> >possibly error-prone.> > > All good arguments ... we will hold off on this :-)> > > Miguel> > > > -------------------------------------------------------> This SF.Net email is sponsored by: SourceForge.net Broadband> Sign-up now for SourceForge Broadband and get the fastest> 6.0/768 connection for only $19.95/mo for the first 3 months!> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > > _______________________________________________> Jmol-developers mailing list> Jmol-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jmol-developers-- Robert M. Hanson, hansonr@stolaf.edu, 507-646-3107Professor of Chemistry, St. Olaf College1520 St. Olaf Ave., Northfield, MN 55057mailto:hansonr@stolaf.eduhttp://www.stolaf.edu/people/hansonr"Imagination is more important than knowledge." - Albert Einstein

By: -
Re: in-line data?  
2004-05-18 16:58
> Incredible. Yes, that worked. I"ll write an application tonight that> utilizes this in an interesting way.That would be great!> Miguel, please explain to me, a newcomer to the jmol business,> how it is being developed.> Are there many people with their own version of this as open> code, of which you are one, or are you the creator and maintainer> of the "official" jmol code?Basically ... the latter.The Jmol project has been around a few years. In the past there were otherpeople who worked on it. Currently Egon and I are the main developers. Weoccasionally get assistance from others, especially in foreign languagetranslations. We are always looking for other developers.Jmol version 10 is a complete rewrite, explicitly designed to be areplacement for RasMol/Chime. I have been making pre-releases since lastfall. There are a handful of serious users who have helped outtremendously by providing valuable feedback and suggestions. They are alsocalled upon to give me some tutoring ... I am not a chemist.There are a few other people out there who have taken the Jmol code andmade "personal" modifications to it. The core "viewer" code is very easyto integrate into a larger Java application. But I do not believe thatthere are any other public lines of development based upon the Jmolsource.You could help out tremendously by being an active user. The primary areathat needs attention is the mechanism for integration with web pages. So,what we really need right now is people who can build serious webapplications (or port existing web applications from Chime to Jmol).Miguel

By: -
Re: in-line data?  
2004-05-19 03:54
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1On Tuesday 18 May 2004 23:58, Miguel wrote:> > Incredible. Yes, that worked. I"ll write an application tonight that> > utilizes this in an interesting way.
> > That would be great!
> > > Miguel, please explain to me, a newcomer to the jmol business,> > how it is being developed.> > Are there many people with their own version of this as open> > code, of which you are one, or are you the creator and maintainer> > of the "official" jmol code?
> > Basically ... the latter.
> > The Jmol project has been around a few years. In the past there were other> people who worked on it. Jmol was originally developed by Dan Gezelter, Notre Dame, South Bend as a MacOS version of XMol... Later Bradley took over as project leader, and 1.5 years ago I became leader... but since then Miguel has done so much, that practically he is leading the v10 branch, while I leaded the v6 branch... which ended in release v9...> Currently Egon and I are the main developers. We> occasionally get assistance from others, especially in foreign language> translations. We are always looking for other developers.Indeed. We need help in, at least, these areas:- - crystallography (space group symmetry implementation)- - animation (interpolation and property (e.g. energy) vs. frame plots)- - internationalisation (some Jmol parts are yet untranslatable...)- - interoperability with QM programs- - analysis plugins (tools that extend the Jmol viewer with tools used in specific research fields, e.g. a plugin interfacing with Platon to do report certain analyses)- - documentation!Egon- -- egonw@sci.kun.nlPhD on Molecular Representation in ChemometricsNijmegen Universityhttp://www.cac.sci.kun.nl/people/egonw/GPG: 1024D/D6336BA6-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.7 (SunOS)iD8DBQFAqx+6d9R8I9Yza6YRAgRrAJ9IE2KhdyXKJJ9KCLL8GnwkCpyC8ACghPpGVgs+tVsADPFt64dpWa2ufj4==cVLa-----END PGP SIGNATURE-----

By: -
Re: in-line data?  
2004-05-19 09:27
E.L. Willighagen wrote:> -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> > On Tuesday 18 May 2004 23:58, Miguel wrote:
> >The Jmol project has been around a few years. In the past there were other
> >people who worked on it. > > > Jmol was originally developed by Dan Gezelter, Notre Dame, South Bend as a > MacOS version of XMol... Later Bradley took over as project leader, and 1.5 > years ago I became leader... but since then Miguel has done so much, that > practically he is leading the v10 branch, while I leaded the v6 branch... > which ended in release v9...> >
> >Currently Egon and I are the main developers.
We occasionally get assistance from others, especially in foreign language translations. We are always looking for other developers.> > > Indeed. We need help in, at least, these areas:> > - - crystallography (space group symmetry implementation) In case you are interested, I have written a program (Visual Basic) that implements all possible space groups and reads xtal files. I don"t really know what else is out there, but this might be useful for error checking or even algorithms. See http://www.stolaf.edu/people/hansonr/mo > > - - animation (interpolation and property (e.g. energy) vs. frame plots) - - internationalisation (some Jmol parts are yet untranslatable...)> - - interoperability with QM programs> - - analysis plugins (tools that extend the Jmol viewer with tools used> in specific research fields, e.g. a plugin interfacing with Platon to do> report certain analyses)> - - documentation! > > Egon> > - -- > egonw@sci.kun.nl > > PhD on Molecular Representation in Chemometrics> Nijmegen University> http://www.cac.sci.kun.nl/people/egonw/ > > GPG: 1024D/D6336BA6> > -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.0.7 (SunOS)> > iD8DBQFAqx+6d9R8I9Yza6YRAgRrAJ9IE2KhdyXKJJ9KCLL8GnwkCpyC8ACghPpG> Vgs+tVsADPFt64dpWa2ufj4=> =cVLa> -----END PGP SIGNATURE-----> > > > -------------------------------------------------------> This SF.Net email is sponsored by: SourceForge.net Broadband> Sign-up now for SourceForge Broadband and get the fastest> 6.0/768 connection for only $19.95/mo for the first 3 months!> http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click > > _______________________________________________> Jmol-developers mailing list> Jmol-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jmol-developers-- Robert M. Hanson, hansonr@stolaf.edu, 507-646-3107Professor of Chemistry, St. Olaf College1520 St. Olaf Ave., Northfield, MN 55057mailto:hansonr@stolaf.eduhttp://www.stolaf.edu/people/hansonr"Imagination is more important than knowledge." - Albert Einstein

By: -
Re: in-line data?  
2004-05-18 17:36
Anyone who responds so quickly to suggestions by serious users is a friend of mine. Here you go for starters. Count me in. -- Robert M. Hanson, hansonr@stolaf.edu, 507-646-3107Professor of Chemistry, St. Olaf College1520 St. Olaf Ave., Northfield, MN 55057mailto:hansonr@stolaf.eduhttp://www.stolaf.edu/people/hansonr"Imagination is more important than knowledge." - Albert Einstein