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.
As for atom indices, perhaps you can imagine where this is going and
why we want "internal" numbers exposed. 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 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? For
example, should I be mindful that some other app, not LiveConnect,
might need to access these interfaces? Right now my method consists of
the following:
---------------------------
src/org/jmol/appletwrapper/WrappedApplet.java
#add an abstract method declaration to
# the WrappedApplet interface
public interface WrappedApplet {
public String getProperty(String infoType);
}
---------------------------
src/org/jmol/api/JmolAppletInterface.java
#add an abstract method declaration to
# the JmolAppletInterface interface
public interface JmolAppletInterface {
public String getProperty(String infoType);
}
---------------------------
src/JmolApplet.java
#add a method to class JmolApplet
# that checks for this being a wrapped applet (why?)
public class JmolApplet
extends org.jmol.appletwrapper.AppletWrapper
implements JmolAppletInterface {
public String getProperty(String infoType) {
return (wrappedApplet == null ? null :
((JmolAppletInterface)wrappedApplet).getProperty(infoType);
}
}
---------------------------
src/org/jmol/applet/Jmol.java
# add the actual method to the Jmol class
# this is the only place additions to the functionality of
# getProperty() would be made
public class Jmol implements WrappedApplet, JmolAppletInterface {
public String getProperty(String infoType) {
[actual def here, calling viewer methods]
}
}
---------------------------
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);
}
-----------------------------
That sound about right?
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?
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? For example, does this last addition make it
so that other applications besides LiveConnect can access the
functions I'm creating? 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.
Bob
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
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&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
