Andreas wrote:

>>>Is this the proper way to retreive this data?
>>>arghh ... NO!
>>>
>>>
> oops ;-)
>
>  > Anything that you want *must* go through the JmolViewer.
>
>
> O.k. So all I need to know about is JmolViewer.java. Makes live easier.
>
>
>  > I prefer to have them in a separate subdirectory because it is easier
> to
>  > manager. But since people think that they are public then it looks like
> I
>  > need to move them all into the viewer directory and remove the 'public'
>  > designations.
>
> hm. What about providing an Interface for JmolViewer? I guess if there
> would have been one in place, it would have stopped me from getting the
> idea to try accessing data from lower levels...

Well, the JmolViewer was supposed to be the entry point. But I didn't make
that very clear.

You have made a very good suggestion. By defining a separate interface in
the api directory (and making the existing JmolViewer an implementation of
that interface) it would be more clear.

>
>  > > How can the insertion code be retreived?
>  >
>  > If the JmolViewer does not provide the information that you need then
> we
>  > will add it.
>
>
> just did a test with e.g. 1h4w.  it seems that getAtomSequenceCode
> returns "221", but not "221A".
> Is there a separate method to get the insertion code for a residue?

Hmmm ... that sounds like a bug.

I think that I intended the insertion code to be part of the 'sequence code'.

Will investigate.



Miguel




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to