Miguel wrote:
I think that you want two getPropery methods.
One takes a string
The other takes two strings
yes, that's what I checked in.
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'.
Now, now, no need to panic! Remember when we had the discussion about
callbacks, and how much of a nuisance they are? Well, much of this
derives from that fact that we are currently implementing callbacks
unnecessarily. For example, while it's fine to implement a callback
when a user clicks or an animation frame changes -- truly asynchronous
events -- we are also relying on callbacks for cases where there is no
need. The first case I took care of was the script command "show
file". (I probably even asked for this.) But this is not an
appropriate script command. It doesn't really act on the
visualization. Rather, it is simply a request for information.
For this sort of information (I think all will agree), we should use
simpler synchronous communication with the applet. This is what
getProperty() now does. You make a query; the applet returns a value.
Very straightforword.
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 should have an application to show you by the end of the day.
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.
Well, I don't know anything about the application. But from Nico's
recent catch, I suspect that the JmolStatusListener interface is meant
to allow interaction with other Java apps. Is that right?
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.
Sure. OK.
*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.
Excellent. OK, I just committed that change. In short:
public String getProperty() methods (2) are now part of Viewer.
JmolViewer class just abstracts viewer.getProperty() methods instead
of implementing them itself.
Sound right?
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
