Oooh, yes, this works nicely.
1) It's a ZIP file. You can name it anything you want using the WRITE
command. Perhaps someone else can adjust the save dialog to allow for this.
2) Two options:
write ZIP "xxx.yyy"
or
write ZIPALL "xxx.yyy"
The difference is that ZIP will include local files only, not remote files,
but ZIPALL will copy remotely accessed files as well so that ALL the files
you could possibly need will be there. Of course, if you plan to have
signed-applet or application capability, ZIPALL is not necessary.
3) The model is loaded using
load "xxx.yyy"
or just by dropping it into Jmol.
4) The collection includes also a JPG, an SPT, and a file "JmolManifest"
which instructs Jmol what to do when the file is loaded (run the script).
The JPG and SPT files have random-digit names so that if you want, you can
unzip a number of these into a single directory, and they shouldn't
overwrite each other. The JPG contains a copy of the script in it, so it can
be used instead of the SPT file if desired. I've left the SPT file in there,
because it's readable and modifiable; the JPG would take special software to
modify the script it holds.
5) The SPT file works from within the ZIP file or after unzipping.
6) To make that work, we have a new file prefix, $SCRIPT_PATH$, which
instructs Jmol to find the file relative to the path that the current script
is being read from. Conveniently, this path can include paths INTO zip
files, so that is what is happening here when the files are part of a ZIP
file collection.
7) Interestingly, $SCRIPT_PATH$ could be anywhere in any script file now,
and it will be changed to the directory name of the script file just before
the script is compiled. So, for example, if in a script you say:
set defaultDirectory "$SCRIPT_PATH$"
then files will be read relative to the directory containing the script
file. That could be useful elsewhere, I think.
8) Definitely needs testing.
Bob
On Mon, Sep 7, 2009 at 7:19 AM, Jonathan Gutow <[email protected]> wrote:
> Two things:
> 1) we've already implemented zipping for large files in WebExport.
> The code is simple as Java has a nice zip package.
> 2) I think that "write ZIP xxxx.yyy" might be OK for the command
> line, but I would like to see a "Save..." in the file menu that opens
> the Save dialog and creates a file with a meaningful extension
> (.jmol ?) that can be emailed or downloaded. The reason I would
> suggest an extension other than .zip is that it tells the user what
> application can directly read the file. My recollection is that if we
> name the script SCRIPT jmol will interpret the zip file correctly.
> Another good example of working this way is the .odt (open document
> text) file, which is a zip archive.
> 3) I think we should probably include at least a 128 x 128 .jpg
> or .png of the view inside the zip file. This could be used for
> iconification and in the multiview catalog that Bob and I discussed a
> while ago.
>
> Jonathan
> On Sep 7, 2009, at 3:10 AM, Robert Hanson wrote:
>
> > Yes, I think we are all set. Took some rearranging of code, but it
> > is all there now. Great idea. Jonathan, do you know how to create
> > ZIP files?
> >
> > We could perhaps implement:
> >
> > write ZIP xxxx.zip
> >
> > which would put it all together, perhaps with the state script also
> > embedded in a JPG. (If you haven't tried that, you should. It's
> > quite startling -- save a JPG, then just drag/drop it back into
> > Jmol. Or display the JPG on a web page, and also do
> >
> > script "myfile.jpg"
> >
> > Bob
> >
> >
> > On Fri, Sep 4, 2009 at 8:18 AM, Jonathan Gutow <[email protected]>
> > wrote:
> > Dear All,
> > Based on what Bob has done below for relative file paths I
> > think we
> > (Bob?) can now make a compressed jmol save file, which is something I
> > was considering doing based on the jmolInstance used for web export.
> >
> > Here's my idea:
> > 1) Copy the data file, state script and any jvxl files associated with
> > view in a single directory with a user chosen name.
> > 2) The state script would need to use the appropriate relative paths
> > (now easy, I think).
> > 3) Zip this into one file with the name <directoryname>.jmol.
> > 4) If I remember how Jmol opens things, I think we can open this file
> > directly and it could be passed from machine to machine without a
> > problem.
> > 5) There are still some issues with updating. I like the safe update
> > method. a) Write updated file with a temporary name. b) Upon
> > successful write erase old file and rename new to the old file name.
> >
> > I was going to use something like this for the multi-viewer we once
> > discussed, but haven't had time to work on that.
> >
> > What do people think?
> >
> > Jonathan
> > On Sep 3, 2009, at 5:19 PM, SourceForge.net wrote:
> >
> > > Feature Requests item #2837721, was opened at 2009-08-14 10:40
> > > Message generated for change (Comment added) made by hansonr
> > > You can respond by visiting:
> > >
> https://sourceforge.net/tracker/?func=detail&atid=379136&aid=2837721&group_id=23629
> > >
> > > Please note that this message will contain a full copy of the
> > > comment thread,
> > > including the initial issue submission, for this request,
> > > not just the latest update.
> > > Category: None
> > > Group: None
> > > Status: Closed
> > > Priority: 5
> > > Private: No
> > > Submitted By: Christopher King (popnose)
> > > Assigned to: Nobody/Anonymous (nobody)
> > > Summary: Use relative address in state files
> > >
> > > Initial Comment:
> > > On one computer, a file, 1edn.pdb, was opened. The state was saved
> > > as 1edn.spt in the same directory as 1edn.pdb. Both files were
> > > transferred to the same directory on another computer. On that
> > > computer, the state file gave an error because the directory
> > > structure was different than on the original computer. Can the
> > > state file be changed to use a relative address for the original
> > > file? Then, I could transfer state files from office to classroom
> > > and not have to worry as much about having the same directory
> > > structure.
> > >
> > >
> > ----------------------------------------------------------------------
> > >
> > >> Comment By: Bob Hanson (hansonr)
> > > Date: 2009-09-03 17:19
> > >
> > > Message:
> > > one more comment. This works by finding
> > > /*file*/"http://rcsb.org/pdb/files/1crn.pdb"; in a state script. If
> > > you had
> > > your own script, you could do the same; just make sure you have /
> > > *file*/
> > > immediately preceding a double-quoted file name.
> > >
> > >
> > >
> > ----------------------------------------------------------------------
> > >
> > > Comment By: Bob Hanson (hansonr)
> > > Date: 2009-09-03 17:15
> > >
> > > Message:
> > > OK, this is done. See Jmol 11.9.2
> > > (http://chemapps.stolaf.edu/jmol/docs/examples-11/Jmol-11.zip and
> > > http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm)
> > >
> > > There are two new options for SCRIPT and WRITE STATE commands. These
> > > are
> > > LOCALPATH and REMOTEPATH. Each takes an argument in quotes. Setting
> > > the
> > > LOCALPATH replaces any file reference in the script, either on
> > > reading or
> > > writing, to that path; setting REMOTEPATH does the same for anything
> > > with
> > > an "http" "https" or "ftp" prefix. So, for example, if you have a
> > > state
> > > that refers to files on a local file system and now you want to run
> > > it but
> > > load files from a different system, you would do something like
> > this:
> > >
> > > script LOCALPATH "" "myfile.spt"
> > >
> > > That says, "whatever the local file path to a file accessed by this
> > > script
> > > command, (in LOAD or SCRIPT commands, for example), make them come
> > > from the
> > > current directory. (This might be on a web host or another local
> > > machine.)
> > >
> > >
> > > script LOCALPATH "data" "myfile.spt"
> > >
> > > would set all local file references to data/....
> > >
> > > If the file reference already contains .../data/... in its path,
> > > then it
> > > is simply truncated to data/....
> > >
> > > Same for REMOTEPATH, but here we are changing only the remote file
> > > references. So, for example, if you had used
> > >
> > > load =1crn
> > >
> > > and then saved the script as "myfile.spt", that script will have in
> > > it:
> > >
> > > load "http://rcsb.org/pdb/files/1crn.pdb";
> > >
> > > So, say now I have that file on disk and don't want to go back to
> > the
> > > server for it. Then I just say:
> > >
> > > script REMOTEPATH "" "myfile.spt"
> > >
> > > This will now read 1crn.pdb from the local drive but otherwise run
> > the
> > > same.
> > >
> > > Bob Hanson
> > >
> > >
> >
> > Dr. Jonathan H. Gutow
> > Chemistry Department [email protected]
> > UW-Oshkosh Office:
> > 920-424-1326
> > 800 Algoma Boulevard FAX:920-424-2042
> > Oshkosh, WI 54901
> > http://www.uwosh.edu/faculty_staff/gutow/
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Jmol-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/jmol-developers
> >
> >
> >
> > --
> > Robert M. Hanson
> > Professor of Chemistry
> > St. Olaf College
> > 1520 St. Olaf Ave.
> > Northfield, MN 55057
> > http://www.stolaf.edu/people/hansonr
> > phone: 507-786-3107
> >
> >
> > 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
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Jmol-developers mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
> Dr. Jonathan H. Gutow
> Chemistry Department [email protected]
> UW-Oshkosh Office:920-424-1326
> 800 Algoma Boulevard FAX:920-424-2042
> Oshkosh, WI 54901
> http://www.uwosh.edu/faculty_staff/gutow/
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Jmol-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
