On Oct 21, 2004, at 6:31 PM, Miguel wrote:
and getAtomSetProperties()
Properties, so some time in the future you want me to put a
java.util.Properties atomSetProperties field in the AtomSetCollection?
I'll hold off on that until I have some of the AtomSetName stuff going.
Correct.
I know that I said that we were not talking about Properties right now,
but since we had the patient opened up on the operating table I went ahead
and put that in. It is not currently used, but it is in there.
Great.
Within the org.jmol.adapter.smarter package I did not change most of the variable names that contain 'model' ... that is your job.
OK. But I assume that you I should stay away from the Atom.modelNumber?
No, I think you should go ahead and change it to atomSetNumber.
Based on your comment below. I will wait till after tonight. Just in case.
Finally, I uncovered something that is important.
The AtomSetCollection class does not have support for atomSetCount. We
*must* add this. But it may require touching several Reader
implementations ... so I need to think about the best way to do it.
Indeed. I was wondering whether we'd need to use an addAtomSet method, but since we really do not have an AtomSet class, that would be confusing.
Correct.
Maybe a protected int newAtomSet() method which would increase the atomSetCount and return it.
Yes, I think something like that would be good.
This atomSetCount could/should then be used for the atom.modelNumber (or really atomSetNumber) in the atoms added/duplicated.
Almost.
Counts are associated with indexes ... and are always 0-based
Numbers can be arbitrary. If unspecified, then they should default to 1-based.
What bothers me, is that we can not really enforce that the atomSetCount is indeed the number used for associating both the atoms and the atomSetName for a particular AtomSet. If the AtomSet were a class, we could. I think...
I think we can enforce it.
I think that when we add an atom we can always force the atomSetNumber to
be the current atomSetNumber.
On the other hand, are there readers that want or need to have direct control over the atomSetNumber used for an AtomSet's atoms? The computational chemistry ones would not, but maybe some of the other ones that I am not too familiar with, may (e.g., Cml or Pdb ones).
Yes. PDB has explicit atomSetNumbers (they call them 'model numbers'). These values can be arbitrary integers.
So, AtomSetCollection should have two methods.
newAtomSet() { ++atomSetCount; currentAtomSetNumber = atomSetCount; }
newAtomSet(int atomSetNumber) { ++atomSetCount; currentAtomSetNumber = atomSetNumber; }
We can also add:
setAtomSetName(String atomSetName) { ... atomSetNames[atomSetCount - 1] = atomSetName; }
As I said, this change is going to affect a lot of Readers. That could be
a little dangerous for you to do. So, if I get a chance I will go ahead
and implement some of this mechanism tonite.
What still confuses me is how the viewer knows which AtomSetIndex to use to get the AtomSetName (through the JmolAdapter) in the case of a pdb file, since the real AtomSetIndex associated with a particular atom may be lost.
On an aside, the atomSetNumber for an atom in a pdb file does not associate it with a particular frame in an animation as it obviously does for something like the NWChemReader?
Ren�
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
