> Miguel,
>
> That sounds good to me. I see, so what you are saying is that
> getAppletInfo is a more generic term that applets in general expose.
> Sure. I've just made a commit for "getProperty", leaving
> getAppletInfo() to be its original meaning.
I think that you want two getPropery methods.
One takes a string
The other takes two strings
> As for atom indices, perhaps you can imagine where this is going and
> why we want "internal" numbers exposed.
I had not anticipated where this was going ... and now I am terrified.
Well, that's a bit of an overstatement ... let's say 'concerned'.
> The idea is that there will be
> additional synchronous "getProperty()" capabilities that will involve
> accessing specific information relating to these internal numbers. So
> the sensible thing to do is exchange those numbers. But, as you say,
> the "extended" data would be more user friendly and take the form of a
> data structure for which this would just be one of several elements.
I think that you need to educate me on the kinds of things that you are
thinking of. This would include the kinds of applications.
> I also need a short lesson in how the applet and app both use
> interfaces to, say, "viewer." I think if I don't have a good sense of
> that, I'll be confusing the app/applet issue. Can you give me a quick
> rundown of how these interfaces should be introduced correctly?
I'm sorry ... I don't understand your question.
> For
> example, should I be mindful that some other app, not LiveConnect,
> might need to access these interfaces?
Yes
> Right now my method consists of
> the following:
[snip]
I think that the ones above this point are OK
> ---------------------------
> src/org/jmol/api/JmolViewer.java
> # add abstract references to new functions called in viewer
>
> abstract public class JmolViewer extends JmolSimpleViewer {
>
> abstract public BitSet getAtomBitSet (String atomExpression);
>
> }
I don't think that this one is right.
I don't think that you should expose this method.
> Have people already been doing this sort of thing with apps -- getting
> specific information about the loaded model? Is there a method for
> that already?
Not too many apps have been written.
> One final question: Should I be doing this differently so that what I
> write might be useful to people interested in interfacing to the app
> rather than the applet?
Yes.
For me there is no difference between the applet and the applications.
> For example, does this last addition make it
> so that other applications besides LiveConnect can access the
> functions I'm creating?
Once you put them in the public API then everyone can get to them.
Access to the public API should be controlled.
I know that there is quite a bit of junk in the public API ... too much
stuff exposed in order to support the application. But, in general, we
should be removing methods, not adding them.
> What I'm wondering is if I should create
> viewer.getProperty as the "guts" of the function rather than it being
> defined in the Jmol class, so that it can be accessible via the
> JmolViewer class.
Yes, absolutely.
*Everything* has to happen underneath Viewer.
Nothing should be implemented in JmolApplet or org.jmol.applet.Jmol ...
except for minimal scaffolding to expose public methods.
Miguel
Miguel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
