Bob: I think I do not understand signed applets, or at least not this one.
I set one of my HTML files to call the signed applet. It calls it and gives me
the signed applet dialog. As I look at it I have three
choices -- run, cancel, or always trust. I understand Run and Always trust.
But I
OK, THERE IS A WORK-AROUND:
jmolInitialize
jmolSetCallback("UseCommandThread","true")
jmolApplet
As far as I can tell, this brings you back to the old behavior. The JAR
files can be anywhere, and the files Jmol reads can be anywhere in or
beneath the JAR file directory. For example:
jmol
Ok, that's good to know. I guess I better move on to RC17.
Otis
On 6/8/2010 1:00 PM, Robert Hanson wrote:
"HOLD" means it's broken, by the way
Is there something not being turned on and off properly by use of the
following couplet?
surely.
set modelkitmode = true
set mode
> Message: 7
> Date: Sat, 5 Jun 2010 01:59:06 +0200
> From: Angel Herr?ez
> Subject: Re: [Jmol-users] Multiple, discontinuous models
>
> Yeah, there it is:
>
> frame all; display 1.2,1.4,1.6
>
> or
>
> frame all; display model=2,model=4,model=6
>
> or
>
> frame all; display */2,*/4,*/6
Beau
Phil, so my suspicion that your problem and mine has the same scent are taking
form. Java
security errors come from folder layouts. I've changed mine and hit a problem,
you have
changed yours and hit another problem. Everything seems to com from the same
cause.
We are needing folder system dr
Bob:
I think this may be a stupid question, but.. I understand your nomenclature
diagram. Are you saying that the pages directory must be inside the jmol
directory which itself must be at the root (top level) of the site. That is,
that you must past through the jmol directory to get to the
> > Actually, the solution looks like using this path set:
> > /jmol
> > .[all jar files here]
> > ./pages
> > .[html here]
Not even that, or I may be coming blind. Fails in both Firefox, IE8,
Chrome. Works in Safari (all Win)
Page is at
etc\Jmol-12.0.RC
> OK, looks like there is a new Firefox security policy:
I will double-check again, but I think that IE is doing me the same.
> For all local files accessed via JavaScript, both the JAR file AND
> the HTML file must be on the path to that file.
Jmol files in a folder BELOW the html page works t
"HOLD" means it's broken, by the way
> Is there something not being turned on and off properly by use of the
> following couplet?
>
> surely.
> set modelkitmode = true
> set modelkitmode = false
>
> Otis
>
> --
> Otis Rothenberger
> chemagic.com
>
>
>
>
>
>
OK, looks like there is a new Firefox security policy:
For all local files accessed via JavaScript, both the JAR file AND the HTML
file must be on the path to that file.
Pretty sure that's new.
The fix for me was to move the Jmol-12 directory into the pages
directory, modify the files, and i
Thanks, Bob. I'm rather puzzled
I think that all has started when I changed from having Jmol files
below the page folder to having them on a sister folder. The script
files are always with Jmol or below it. So it's the position relative
to the html that makes the difference.
Comparing to the a
UFF.txt is a resource within the Jar file. Specifically it is in:
JmolApplet0_Minimize.jar/org/jmol/minimize/forcefield
JmolAppletSigned0_Minimize.jar/org/jmol/minimize/forcefield
If you use
set debug
you should see its contents listed when the minimizer runs.
Very odd that the system can't
El 8 Jun 2010 a las 12:02, Philip Bays escribió:
> Obviously I have to learn to use Jmol.js:-)
Well, that's really easy. But won't keep you away from the cache
problems :-)
Good luck
--
ThinkGeek and WIRED's GeekDad t
Thanks all. I am looking at the suggestions.
However, I found that if I go to another account on my macing, the pages work
fine in Firefox. This clearly means it is a cache problem. I have gone back
to my account, as as Egan said, it is a pain to determine how to delete
everything that nee
OK, so on a Mac here at St. Olaf (sorry -- no details) this site worked
fine.
The file can't be opened locally because the jar file is not on the path to
it. Generally speaking, you can't use ../../Jmol for the Jar file
location and then just ./.pdb for the file.
Also, Phil, if you aren't
The critical information comes from the Java console:
urlImage=jar:
http://www.saintmarys.edu/~pbays/Jmol/JmolApplet.jar!/jmol75x29x8.gif
[this tells us where the Jar file is located]
FileManager.getAtomSetCollectionFromFile(Acyclic/M5/R.pdb)
FileManager opening
http://www.saintmarys.edu/~pbays/
Works for me using Firefox on a Mac if I follow the link below.
MacOS 10.6.3, Java 1.6.0_20. I'm getting Jmol 12.0.RC12 from your server.
Have the people having problems clear their caches and restart their browsers.
It might be worth rebooting the machine as well.
Jonathan
On Jun 8, 2010, at
Phil-
The Jmol related problem changes work for me on XP with Firefox, Chrome,
and MSIE.
Java 1.6.0_19
Firefox 3.6.3
Is it possible that your use of innerHTML to load a the original applet
is causing issues on some browsers/platforms when you use the newer Jmol
applet?
Another thought: Wo
This is the summary and a test case:
1. Problem is there only for local files, not from server. Seems to
be related to Jmol reading text files (either scripts or the UFF.txt
file embedded somehow inside Jmol) from a folder where the applet
jars are but the webpage is not.
Main_folder
|
But here are the issues:
1. The programs have worked in the past, and were even working last week, I
think. They were written about 5 years ago and have been in use since then
with classes. (This was pre-Hanson time).
2. I have reorganized the site with appropriate (I think) adjustments in path
Well, I don't think that Jonathan's well-based explanation says why
this didn't happen to Phil with a previous version of Jmol.
I see this security rules are a complex situation.
Also, maybe by chance, but I'm having seeming different problems that
come also to Java security issues. I'm testing
Phil,
This is a problem specifically with how Mozilla browsers on the Mac pass local
paths. This has been a problem for years. For local running of pages on a Mac
you need to use a different browser. The issue is that the Mozilla browsers
insist on passing absolute paths through the javascri
Further, even accounting for tricky security policies, I cannot
imagine why the very same command works from the console, and what
has minimize to do with the security. (minimize is also failing from
a button, not from console or popup menu)
--
Phil, I don't know.
I'm starting to see ghosts :-)
I've just made a simple page and gone back to Jmol 11.6, just to
confirm this is or not an issue of recent Jmol versions. It is not.
The command that fails when called in a button is OK when entered at
the console.
The paths are correct, the Ja
Angel:
Are your issue and mine related? I use a random number generator to choose
which file to load. The first one is loaded fine. But when I push a button to
reload (another random numbered file), I get the exception.
Phil
On Jun 8, 2010, at 6:57 AM, Angel Herráez wrote:
> The same probl
The same problem stays in 12.0.RC17 and I'm finding more strange
behaviours that, altough unrelated in principle, may have the same
origin:
I am calling a script file (that acts on the current model, does not
load anything). When invoked from a button in the page, if raises a
Java security err
Bob:
The jar file is in a directory (Jmol) at the Sites level. So Acyclic -- the
program calling the applet -- is below is below it it as prescribed. It works
non-Mozilla browsers on the mac in Safari. And the same setup is on the web
where I observe the same issue.
Phil
On Jun 8, 2010, at
27 matches
Mail list logo
