jmol-developers

[Jmol-developers] Correction to Axes.java code...

[pim s. <pim...@go...>]

"axes scale ..." did not work for the "axes unitcell" option. This is
a desired option, however, especially when using a lot of periodic
images of the lattice, where the axis system gets lost in the center,
but the axes should keep the vectors and base coordinates of the main
lattice.

My suggestion:

Index: src/org/jmol/shape/Axes.java
===================================================================
--- src/org/jmol/shape/Axes.java        (revision 8017)
+++ src/org/jmol/shape/Axes.java        (working copy)
@@ -64,6 +64,12 @@
       axisPoints[0].add(offset, vectors[4]);
       axisPoints[1].add(offset, vectors[2]);
       axisPoints[2].add(offset, vectors[1]);
+      // UnitCell should not use setScale as it has only 3 axisPoints
+      for (int i = 3; --i >= 0;) {
+        axisPoints[i].x *= viewer.getAxesScale()/2.0;
+        axisPoints[i].y *= viewer.getAxesScale()/2.0;
+        axisPoints[i].z *= viewer.getAxesScale()/2.0;
+      }
       return;
     } else if (axesMode == JmolConstants.AXES_MODE_MOLECULAR) {
       originPoint.set(0, 0, 0);

This is tested for tetragonal, orthorhombic and rhombohedral unit cells.

Now if I would like to put this back to the SVN system, can I use the
info written in
http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
of the text there seems not to fit, e.g.:

What is the preferred text to use as the commit message?
the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
on what prerelease I would be working.
Also the svn copy commands don't seem to apply to my case.

Any help is appreciated!

-- 
Greetings, Pim
http://www.molmod.com

[Jmol-developers] Fwd: Correction to Axes.java code...

[pim s. <pim...@go...>]

This didn't seem to reach the list the first time, therefore I send it again:

---------- Forwarded message ----------
From: pim schravendijk <pim...@go...>
Date: Jul 27, 2007 2:52 PM
Subject: Correction to Axes.java code...
To: jmo...@li...


"axes scale ..." did not work for the "axes unitcell" option. This is
a desired option, however, especially when using a lot of periodic
images of the lattice, where the axis system gets lost in the center,
but the axes should keep the vectors and base coordinates of the main
lattice.

My suggestion:

Index: src/org/jmol/shape/Axes.java
===================================================================
--- src/org/jmol/shape/Axes.java        (revision 8017)
+++ src/org/jmol/shape/Axes.java        (working copy)
@@ -64,6 +64,12 @@
       axisPoints[0].add(offset, vectors[4]);
       axisPoints[1].add(offset, vectors[2]);
       axisPoints[2].add(offset, vectors[1]);
+      // UnitCell should not use setScale as it has only 3 axisPoints
+      for (int i = 3; --i >= 0;) {
+        axisPoints[i].x *= viewer.getAxesScale()/2.0;
+        axisPoints[i].y *= viewer.getAxesScale()/2.0;
+        axisPoints[i].z *= viewer.getAxesScale()/2.0;
+      }
       return;
     } else if (axesMode == JmolConstants.AXES_MODE_MOLECULAR) {
       originPoint.set(0, 0, 0);

This is tested for tetragonal, orthorhombic and rhombohedral unit cells.

Now if I would like to put this back to the SVN system, can I use the
info written in
http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
of the text there seems not to fit, e.g.:

What is the preferred text to use as the commit message?
the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
on what prerelease I would be working.
Also the svn copy commands don't seem to apply to my case.

Any help is appreciated!

--
Greetings, Pim
http://www.molmod.com


-- 
Greetings, Pim
http://www.molmod.com

Re: [Jmol-developers] Fwd: Correction to Axes.java code...

[Nicolas V. <nve...@nu...>]

pim schravendijk a écrit :
> Now if I would like to put this back to the SVN system, can I use the
> info written in
> http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
> of the text there seems not to fit, e.g.:
>
> What is the preferred text to use as the commit message?
> the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
> on what prerelease I would be working.
> Also the svn copy commands don't seem to apply to my case.
>   
The page you are refering to is mostly a reminder for admins on what to 
do exactly when we needed to do a new release of Jmol (available on 
sourceforge in the download section).
That's why some of the text doesn't fit with committing a bug fix or a 
new feature ;)

For the text, try to use a (short but) descriptive text of the 
modification, so that when when browsing through the history of 
modification we know what to expect in the modification.

There's no description on how to check out / update / commit on the Wiki 
(nobody thought of adding it before apparently), except on the Eclipse page.

If you have troubles, tell me.

Nico

Re: [Jmol-developers] Fwd: Correction to Axes.java code...

[Nicolas V. <nve...@nu...>]

I forgot to mention a few things that can be useful for every developer 
for Jmol.

Starting a few releases ago, Bob and I decided to keep a list of 
modifications contained in each release. So when committing a 
modification, you should also modify the Jmol.properties file in 
src/org/jmol/viewer. Simply use the same format as the other modifications.

For exemple, the current Jmol.properties file starts with :

version=11.3.8_dev

# --------------------------------------------------------------------

That means that the next release will probably be 11.3.8 and there has 
been no modifications yet in Jmol for this new release
After your modification, the Jmol.properties file should start with:

version=11.3.8_dev

# bug fix: "axes scale ..." did not work for the "axes unitcell" option

# --------------------------------------------------------------------

When I release a new version of Jmol, I simply copy / paste this in the 
change log accessible on sourceforge with the new version, and I modify 
the Jmol.properties file to prepare for the next version.

Nico

pim schravendijk a écrit :
> Now if I would like to put this back to the SVN system, can I use the
> info written in
> http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
> of the text there seems not to fit, e.g.:
>
> What is the preferred text to use as the commit message?
> the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
> on what prerelease I would be working.
> Also the svn copy commands don't seem to apply to my case.
>   
The page you are refering to is mostly a reminder for admins on what to
do exactly when we needed to do a new release of Jmol (available on
sourceforge in the download section).
That's why some of the text doesn't fit with committing a bug fix or a
new feature ;)

For the text, try to use a (short but) descriptive text of the
modification, so that when when browsing through the history of
modification we know what to expect in the modification.

There's no description on how to check out / update / commit on the Wiki
(nobody thought of adding it before apparently), except on the Eclipse page.

If you have troubles, tell me.

Nico

[Jmol-developers] LiveConnect Alternatives

[Albion B. <ba...@ms...>]

Sorry if this is the wrong list (maybe post to users?) for this  
question, although it seems a little technical for that list.

There was a time when you could create java applets that would  
communicate with other java applets in a webpage via LiveConnect. You  
would compile your applets with the JSObject class provided by  
Netscape, and issue javascript commands that could be targeted to  
named applets specifically.

Evidently Mozilla (Firefox) has abandoned LiveConnect in favor of  
other technologies. I would like to explore creating applets that can  
communicate with Jmol and embed them in webpages. I once had a  
library of Java applets that could communicate with Chime (albeit a  
plug-in), that used LiveConnect.

Is anyone aware of how to get my applet to script a Jmol applet in  
Mozilla? This is simply applet to applet communication in the same  
webpage. I have searched the archives, and the web, but haven't  
exactly come across a definitive answer and a lot of references to  
the now defunct LiveConnect.

Cheers,

Albion

Re: [Jmol-developers] LiveConnect Alternatives

[Gary K. <gke...@gm...>]

Hi Albion,

I'm using Mozilla's XULRunner to tie together Jmol with some quantum
chemistry program input processing tools.  This uses XUL and Java
Script for the most part.  The way I handle the Jmol interface is to
have a pop-up window with a stripped down browser dedicated to Jmol
using the XUL <browser> tag with an event listener.  Using Java
Script, I dynamically create HTML web pages which use Bob Hanson's
scripts to interface Jmol.  My stuff is somewhat complicated because
I'm writing an application program that ties together other existing
tools in other languages with XUL GUIs.  I think AJAX may work for you
building upon the Jmol scripts.  Did you look at
http://jmol.sourceforge.net/docs/, in particular the "Scripting for
Jmol" section?

If you'd like to see some code snippets for my XUL interface to Jmol,
let me know.

All the best,
Gary

On 7/30/07, Albion Baucom <ba...@ms...> wrote:
> Sorry if this is the wrong list (maybe post to users?) for this
> question, although it seems a little technical for that list.
>
> There was a time when you could create java applets that would
> communicate with other java applets in a webpage via LiveConnect. You
> would compile your applets with the JSObject class provided by
> Netscape, and issue javascript commands that could be targeted to
> named applets specifically.
>
> Evidently Mozilla (Firefox) has abandoned LiveConnect in favor of
> other technologies. I would like to explore creating applets that can
> communicate with Jmol and embed them in webpages. I once had a
> library of Java applets that could communicate with Chime (albeit a
> plug-in), that used LiveConnect.
>
> Is anyone aware of how to get my applet to script a Jmol applet in
> Mozilla? This is simply applet to applet communication in the same
> webpage. I have searched the archives, and the web, but haven't
> exactly come across a definitive answer and a lot of references to
> the now defunct LiveConnect.
>
> Cheers,
>
> Albion
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Jmol-developers mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>

Re: [Jmol-developers] LiveConnect Alternatives

[Bob H. <ha...@st...>]

Albion, my understanding (just from reading a few blogs such as 
http://boomswaggerboom.wordpress.com/2007/04/16/javaplugin-cleanup-for-mozilla-20/) 
suggests that this will not be an issue -- that the replacement 
technology is a full replacement, and developers using JSObject won't 
notice any changes. Can anyone provide evidence one way or the other on 
this?

Bob Hanson


Albion Baucom wrote:

>Sorry if this is the wrong list (maybe post to users?) for this  
>question, although it seems a little technical for that list.
>
>There was a time when you could create java applets that would  
>communicate with other java applets in a webpage via LiveConnect. You  
>would compile your applets with the JSObject class provided by  
>Netscape, and issue javascript commands that could be targeted to  
>named applets specifically.
>
>Evidently Mozilla (Firefox) has abandoned LiveConnect in favor of  
>other technologies. I would like to explore creating applets that can  
>communicate with Jmol and embed them in webpages. I once had a  
>library of Java applets that could communicate with Chime (albeit a  
>plug-in), that used LiveConnect.
>
>  
>
certainly we have been doing this for some time. Is there some reason to 
believe that Mozilla Firefox 2.0 won't support this?

>Is anyone aware of how to get my applet to script a Jmol applet in  
>Mozilla? This is simply applet to applet communication in the same  
>webpage. I have searched the archives, and the web, but haven't  
>exactly come across a definitive answer and a lot of references to  
>the now defunct LiveConnect.
>  
>

Far as I know you just use JavaScript to link the two applets. I'm 
interested, though, if people have used direct connections between 
applets in relation to Jmol.

>Cheers,
>
>Albion
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>Jmol-developers mailing list
>Jmo...@li...
>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>  
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

Re: [Jmol-developers] LiveConnect Alternatives

[Albion B. <ba...@ms...>]

Thanks Bob.

Yah, I came across that forum message. I guess I am just not clear on  
the what the alternative is. AJAX has been suggested, but a lot of  
these technologies seem overly complicated for what I would think  
would be simple applet<->applet communication. But maybe I just  
haven't done my homework :)

I guess I am going to have to do some research as it is not obvious  
how to use the replacement technology. I'll be sure to let everyone  
know when I have something working.

Please pipe-up if you know how to get an applet to talk to a Jmol  
applet while embeded in a webpage.

Thanks

Albion

On Aug 5, 2007, at 10:44 AM, Bob Hanson wrote:

> Albion, my understanding (just from reading a few blogs such as
> http://boomswaggerboom.wordpress.com/2007/04/16/javaplugin-cleanup- 
> for-mozilla-20/)
> suggests that this will not be an issue -- that the replacement
> technology is a full replacement, and developers using JSObject won't
> notice any changes. Can anyone provide evidence one way or the  
> other on
> this?
>
> Bob Hanson

Re: [Jmol-developers] LiveConnect Alternatives / syncing applets

[Bob H. <ha...@st...>]

I have two Jmol applets talking to each other directly. See

http://chemapps.stolaf.edu/jmol/docs/examples-11/sync.htm

which has two synced applets that are driven based on which one has the 
focus.

And, if that works, try:

http://chemapps.stolaf.edu/jmol/docs/examples-11/sync4.htm

which has four applets, all synced, but only two drivers.

Does this work any better on Macs?

The JavaScript code is simply:

 _jmolGetApplet("B").syncScript("slave")
 _jmolGetApplet("A").syncScript("on")

Eric Martz, you might want to experiment with this. The following 
commands are possible:

 _jmolGetApplet("A").syncScript("slave")  // designate as slave applet
 _jmolGetApplet("A").syncScript("on") // designate as driver and turn 
syncing on
 _jmolGetApplet("A").syncScript("off") // stop syncing

I think you have to designate the slaves before you start syncing.


   

-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

Re: [Jmol-developers] Fwd: Correction to Axes.java code...

[pim s. <pim...@go...>]

Excellent! Thank you!

I recently copied the check out information from the static jmol page to:

http://wiki.jmol.org:81/index.php/Release_Procedures

I will restructure it further and add the information you gave here to
it as well.

On 7/30/07, Nicolas Vervelle <nve...@nu...> wrote:
> I forgot to mention a few things that can be useful for every developer
> for Jmol.
>
> Starting a few releases ago, Bob and I decided to keep a list of
> modifications contained in each release. So when committing a
> modification, you should also modify the Jmol.properties file in
> src/org/jmol/viewer. Simply use the same format as the other modifications.
>
> For exemple, the current Jmol.properties file starts with :
>
> version=11.3.8_dev
>
> # --------------------------------------------------------------------
>
> That means that the next release will probably be 11.3.8 and there has
> been no modifications yet in Jmol for this new release
> After your modification, the Jmol.properties file should start with:
>
> version=11.3.8_dev
>
> # bug fix: "axes scale ..." did not work for the "axes unitcell" option
>
> # --------------------------------------------------------------------
>
> When I release a new version of Jmol, I simply copy / paste this in the
> change log accessible on sourceforge with the new version, and I modify
> the Jmol.properties file to prepare for the next version.
>
> Nico

--
Greetings, Pim
http://www.molmod.com

Re: [Jmol-developers] Correction to Axes.java code...

[Bob H. <ha...@st...>]

I've just checked in something like this, which also takes into account 
the possibility that the offset is not {0,0,0} and that the unitcell box 
should not over-draw the axes.
It's unfortunate that the default axesScale has to be 2.0 -- it DOES -- 
so that unitcell axes scales have to be given in units of a/2, b/2, c/2, 
but that's the way it is, I guess.

Bob

pim schravendijk wrote:

>"axes scale ..." did not work for the "axes unitcell" option. This is
>a desired option, however, especially when using a lot of periodic
>images of the lattice, where the axis system gets lost in the center,
>but the axes should keep the vectors and base coordinates of the main
>lattice.
>
>My suggestion:
>
>Index: src/org/jmol/shape/Axes.java
>===================================================================
>--- src/org/jmol/shape/Axes.java        (revision 8017)
>+++ src/org/jmol/shape/Axes.java        (working copy)
>@@ -64,6 +64,12 @@
>       axisPoints[0].add(offset, vectors[4]);
>       axisPoints[1].add(offset, vectors[2]);
>       axisPoints[2].add(offset, vectors[1]);
>+      // UnitCell should not use setScale as it has only 3 axisPoints
>+      for (int i = 3; --i >= 0;) {
>+        axisPoints[i].x *= viewer.getAxesScale()/2.0;
>+        axisPoints[i].y *= viewer.getAxesScale()/2.0;
>+        axisPoints[i].z *= viewer.getAxesScale()/2.0;
>+      }
>       return;
>     } else if (axesMode == JmolConstants.AXES_MODE_MOLECULAR) {
>       originPoint.set(0, 0, 0);
>
>This is tested for tetragonal, orthorhombic and rhombohedral unit cells.
>
>Now if I would like to put this back to the SVN system, can I use the
>info written in
>http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
>of the text there seems not to fit, e.g.:
>
>What is the preferred text to use as the commit message?
>the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
>on what prerelease I would be working.
>Also the svn copy commands don't seem to apply to my case.
>
>Any help is appreciated!
>
>  
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

Re: [Jmol-developers] Correction to Axes.java code...

[Bob H. <ha...@st...>]

oh -- that's for 11.3.8 only, not 11.2.8, as this is not a bug fix. (Or 
is it?)

Bob

pim schravendijk wrote:

>"axes scale ..." did not work for the "axes unitcell" option. This is
>a desired option, however, especially when using a lot of periodic
>images of the lattice, where the axis system gets lost in the center,
>but the axes should keep the vectors and base coordinates of the main
>lattice.
>
>My suggestion:
>
>Index: src/org/jmol/shape/Axes.java
>===================================================================
>--- src/org/jmol/shape/Axes.java        (revision 8017)
>+++ src/org/jmol/shape/Axes.java        (working copy)
>@@ -64,6 +64,12 @@
>       axisPoints[0].add(offset, vectors[4]);
>       axisPoints[1].add(offset, vectors[2]);
>       axisPoints[2].add(offset, vectors[1]);
>+      // UnitCell should not use setScale as it has only 3 axisPoints
>+      for (int i = 3; --i >= 0;) {
>+        axisPoints[i].x *= viewer.getAxesScale()/2.0;
>+        axisPoints[i].y *= viewer.getAxesScale()/2.0;
>+        axisPoints[i].z *= viewer.getAxesScale()/2.0;
>+      }
>       return;
>     } else if (axesMode == JmolConstants.AXES_MODE_MOLECULAR) {
>       originPoint.set(0, 0, 0);
>
>This is tested for tetragonal, orthorhombic and rhombohedral unit cells.
>
>Now if I would like to put this back to the SVN system, can I use the
>info written in
>http://wiki.jmol.org/index.php/Release_Procedures#Release_build? Some
>of the text there seems not to fit, e.g.:
>
>What is the preferred text to use as the commit message?
>the  page says: svn commit -m "prerelease 10.3.1", but I wouldn't know
>on what prerelease I would be working.
>Also the svn copy commands don't seem to apply to my case.
>
>Any help is appreciated!
>
>  
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

Re: [Jmol-developers] Correction to Axes.java code...

[pim s. <pim...@go...>]

If it would have been a bug, people would have been complaining by now
:) I guessed the factor 2.0 makes sense as the axes is for all other
cases (molecular and window axes) extending in two opposite directions
from the origin, making the distance of one axis-end from the origin
half of the total axislength.
I see now I also should have taken into account the difference with
the offset, I will take a look at how you did that tomorrow.

Thanx!

On 8/5/07, Bob Hanson <ha...@st...> wrote:
> oh -- that's for 11.3.8 only, not 11.2.8, as this is not a bug fix. (Or
> is it?)
>
> Bob

--
Greetings, Pim
http://www.molmod.com


-- 
Greetings, Pim
http://www.molmod.com