OK, I've moved Jmol.properties into viewer. In fact, that was the
problem. So I'll direct those Class.forName() calls to their former
locations, and we should be all set. Thank you, Nico. It is always nice
to have a simple solution.
I'll divided the readers in as basic, xml, and more. Certainly that is
all up for discussion.
Currently "basic" includes xyz, pdb, cif, and mol. We could certainly
split this as fine as we wish -- one reader per package if we wanted to.
But that's probably unnecessary. Maybe there are a few subsets of "more"
that could be broken out, or we could split off pdb and cif as separate
ones, since they are pretty big.
This is currently broken for signed applets.
We need to get the manifests straightened out. Nico, can we just not
have manifests for all the individual files, and then have just one
"sealed: true" in applet0 for the whole set?
The build file I am using is build-applet-test.xml. These jar file
specifications need to be put into build.xml along with the proper
manifests.
Nico, I added PatternMatcher to org.jmol.smiles. If you would prefer it
not be there, I'll move it. We now have an interface to access it, so it
doesn't matter to me where it goes.
But if it goes somewhere else, we need to be sure to indicate that in
the Jar file and the applet-classes file.
Here are the file sizes. Note that the required files only add up to 650
Kb. Quite an improvement, I think!
1,000,021 JmolApplet.jar
required:
x 10,742 JmolApplet0.jar
x 55,974 JmolAppletJars.jar
x 31,586 JmolAppletMain.jar
x 146,504 JmolAppletMisc.jar
x 28,084 JmolAppletPopup.jar
x 360,695 JmolAppletViewer.jar
optional; loaded when needed:
72,921 JmolAppletJvxl.jar
7,109 JmolAppletQuantum.jar
14,242 JmolAppletReadersCifPdb.jar
4,276 JmolAppletReadersMolXyz.jar
60,437 JmolAppletReadersMore.jar
22,182 JmolAppletReadersXml.jar
51,927 JmolAppletShapeBio.jar
35,680 JmolAppletShapeSpecial.jar
7,975 JmolAppletSmiles.jar
98,211 JmolApplet_i18n.jar
aside -- I found a bug in the GAMESS reader for molecular orbitals --
it's not mapping the orbitals correctly. I'll fix that.
Nicolas Vervelle wrote:
> Bob Hanson wrote:
>
>> Nico and Miguel,
>>
>> It appears that any classes in packages in
>>
>> org.jmol.*
>>
>> are read in full regardless of their access. Even when
>>
>> org.jmol.readers contains a single class that does nothing
>> at all (I mean, totally empty), it is read.
>>
>> If, on the other hand, the desired optional classes are in, say,
>>
>> org.jmoloptions.readers
>>
>> then we are ok. They do not get loaded until needed.
>>
>
> Good.
>
>> For example, I created:
>>
>> org.jmoloptions.readers.XyzReader.class
>> org.jmoloptions.smilesmatcher.PatternMatcher.class
>>
>> and when Jmol loads now, that reader's jar file is only downloaded
>> after caffeine.xyz is opened, and the smiles code is only downloaded
>> after "select substructure()" is issued from the console.
>>
>
> And this time, the don't get both loaded at the same time ?
> That's good, we then have a way to speed the loading part.
>
>
>> So I think I have at least defined the conditions for optional
>> downloading --
>> optional classes cannot be in org.jmol.
>>
>> Before we act on this, I'd like someone to confirm that this is the
>> defined behavior and that we are not just missing some sort of simple
>> thing that would make any largescale changes unnecessary.
>>
>
> If it's really the case, then for me, it seems to be a bug with
> INDEX.LIST, but then why does it work with org.jmoloptions ?
>
> Just an idea :
> Could it be related to org/jmol/Jmol.properties ? Do we still have the
> same problem if we modify the code to look for Jmol.properties in
> org/jmol/viewer/ instead ?
> It should be the only file that is directly in org/jmol, maybe it can
> explain this problem.
>
>> If we do need to make changes, I suggest creating something like the
>> following options:
>>
>> org.jmoloptions.jvxl
>> org.jmoloptions.popupmenu
>> org.jmoloptions.quantum
>> org.jmoloptions.readers0 (some subset of readers)
>> org.jmoloptions.readers1 (some subset of readers)
>> org.jmoloptions.readers2 (some subset of readers)
>> org.jmoloptions.shapebio
>> org.jmoloptions.shapespecial
>> org.jmoloptions.smiles
>>
>> Then, as Nico pointed out, we don't need any sort of additional user
>> flags.
>> I think I've done what I can on this until I hear from you two.
>>
>
> If moving Jmol.properties doesn't solve the problem, then creating
> org.jmoloptions seems a good option.
> It's still strange, because there's clearly a bug with INDEX.LIST if
> it doesn't work.
>
> Nico
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
