On Dec 31, 2004, at 9:47 AM, Miguel wrote:
Rene wrote:
I had expected the implementation of a method in the Viewer that would
allow one to get the array of atoms for a particular ModelIndex, as
opposed to having to loop through all the atoms and determining whether
they are in the desired model to see whether or not they need to be
ignored.
I am thinking of making a change to the implementation.
Atom Indexes are currently sequential within a model.
Therefore, the set of atoms in a model could be defined by a starting index and an atom count.
(One of the main problems with this is that it would preclude/complicate
things if we wanted to add atoms to a model after it was created)
If each model had its own array or vector of list of atoms, none of this would be a problem.
How about a method that just returns an array of atom indexes for a particular model. As long as the implementation is forced to have sequential atom indices it would just return an array of sequential numbers. If, down the line, the implementation changes, we would not have to get into too many problems :-).
Then another question pops up: do we need something like that for bonds, and other multiple-atom spanning type of information... Starting to get tedious.
If one were to write a multi-step xyz file for a subset of
models in the input, one would have to loop through all atoms for every
model to be output in a step...
I agree that it is not pretty. But in reality the cost of this iteration
is insignificant.
I agree, but I think that if one has to implement this kind of iterations in different locations, it may be useful to fold in that functionality directly at a lower level.
For the time being this is a workable solution.
Then again, if one returns an array of references to the the low level atom class,
*please* do not do that.
I wasn't planning on that.
Actually I would not even have dared to modify the JmolViewer class. (I learned my lesson :-).
I consolidated several packages into org.jmol.viewer so that the methods
would not be public. I did this to try to prevent people from looking
inside the data structures.
one probably could modify them, which would cause problems since the viewer may not know about the modifications (i.e., one would really want a 'read-only' version of the AtomSet that is associated with a modelIndex...).
I know that the JmolViewer API needs more functionality in some areas. It
also needs to have many entry points removed.
Even the Jmol application should be accessing everything through the api.
That is how we will ensure that the API has adequate functionality.
Agreed.
Ren�
Miguel
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
