Miguel, et al.,
I've committed the following getProperty() implementation:
applet.getProperty("atomDetail","")
for example:
atominfo = jmolAppletX.getProperty("atomDetail","selected")
This immediately returns a JSON (JavaScript Object Notation) string
that shows detail about the atoms in the
On Feb 6, 2006, at 5:59 p, Bob Hanson wrote:
Timothy Driscoll wrote:
I know your current change is invisible to the end user, Bob; it
just reminded me that most users do not follow the developers
list, and they should be in the loop on this effort IMO.
I wasn't sure to what extent users
I wasn't sure to what extent users should be updated when the change
is only in the commit stage, not the release stage. But I think you
mean, just passing the whole idea of such a change by users before
actually committing? That's definitely what I'm doing with the connect
issue. I have the co
On Feb 6, 2006, at 4:08 p, Bob Hanson wrote:
I've committed to CVS a slight modification of the callback system.
In particular, for script message callbacks (that "Jmol executing
script" message) the JavaScript interface now allows for:
mymessagecallbackfunction(target,message,additionalinfo
I've committed to CVS a slight modification of the callback system.
In particular, for script message callbacks (that "Jmol executing
script" message) the JavaScript interface now allows for:
mymessagecallbackfunction(target,message,additionalinfo)
where that third parameter is the script that
De: Bob Hanson <[EMAIL PROTECTED]>
>
>> Yes, easy (but not often useful because you can forget build.xml most of the
>> time under Eclipse): right-click on build.xml and select Run As / Ant Build
>> ...
>> In the Ant window, you can select which targets to run and in which order.
>
>So what I do
[EMAIL PROTECTED] wrote:
Yes, easy (but not often useful because you can forget build.xml most of the
time under Eclipse): right-click on build.xml and select Run As / Ant Build ...
In the Ant window, you can select which targets to run and in which order.
So what I do is unclick [x] Main i
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
> Hi all,
> I have only recently joined the Jmol lists so have missed out on
> some of the discussion re Jmol and JCAMP-DX.
Welcome to the list ... and to the Jmol community!
> For 8 years we licensed our C++ code to MDL that could display the various
> JCAMP-DX protocols for IR/NMR/MS as well a
Hi all,
I have only recently joined the Jmol lists so have missed out on
some of the discussion re Jmol and JCAMP-DX.
For 8 years we licensed our C++ code to MDL that could display the various
JCAMP-DX protocols for IR/NMR/MS as well as UV/Vis and Chromatograms
stored in this style.
With the con
De: "Miguel" <[EMAIL PROTECTED]>
>I do this by saying:
>
> ant clean main
>
>You should *always* do a clean build before doing a checkin.
>
>I cannot tell you how to do it using eclipse ... but I am sure that it is
>easy.
;)
Yes, easy (but not often useful because you can forget build.xml most of
De: Bob Hanson <[EMAIL PROTECTED]>
>Bothers me that build.xml didn't catch that change and see that it had
>to recompile the app class file. I really don't understand why it
>compiled for me but not you.
It's because I didn't see the error with build.xml, but with Eclipse built-in
build. I rar
> Bothers me that build.xml didn't catch that change and see that it had
> to recompile the app class file. I really don't understand why it
> compiled for me but not you.
ant + build.xml will only compile things based upon source file modified
dates.
Sometimes when you change things you need to
> 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.
nico,
my fault. I added that. How come it's compiling for me?
Is it because build.xml doesn't catch the dependencies of those applet
class files? Hmm.
Ah, yes. Now I see where changing an interface can be tricky, because
any class implementing it MUST have that method as described in the
int
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 t
> Miguel,
> I asked you this question so that I could figure out if the code
> currently
> in jcamp should be maintained or it could be phased out in order to
> incorporate any existing code in Jmol.
OK ... although I am still puzzled.
The purpose of the jcamp applet is to display jcamp data. I
> Hi Miguel,
>
> I have been checking the jmol forums and it seems that there may be some
> duplication of efforts on developing a jcamp display applet.
Perhaps
> Our original source code was from Henry Rzepa and I was led
> to believe it is open source.
I think that the concern is that the sou
I have just done a cvs update, and the code is not compiling any more:
"The type Jmol.MyJmolStatusListener must implement the inherited abstract
method JmolStatusListener.setStatusMessage(String, String)" Jmol.java
Jmol/src/org/openscience/jmol/app line 1339
Nico
--
Miguel,
I asked you this question so that I could figure out if the code
currently in jcamp should be maintained or it could be phased out in
order to incorporate any existing code in Jmol. The reason for this is
that jcamp currently reads text based jdx files and plots the data
read. With the req
Shravan,
Last week you sent me a .jdx file and asked if Jmol could read it.
Jmol reads many file formats that contain atom coordinates.
As I understand it, .jdx files contain spectral data, but do not contain
atom coordinate data. Therefore, from Jmol's perspective, there is nothing
to read.
So
Shravan,
There are discussions on the jmol-developers list regarding your jcamp
development. Other people are interested in your progress in the jcamp
applet ... and there are some questions about someone else who has a
similar project.
Q: Are you on the jmol-developers mailing list?
If not, re
> I've just made a commit that adds an example of what I'm after in my
> first "real" contribution to Jmol:
>
> applet.getAppletInfo("atomList","")
>
> With this addition, one can query the applet to find out which atoms are
> in a particular set.
> So, for example, one could query:
>
> applet.get
>
> Hi,
>
> I am investigating if it is possible to integrate JmolViewer into my Java
> program. I notice that JmolViewer accepts Ramol script on the
> commandline when being launched. After that, users have to right click the
> mouse to select command from a pop up menu. My question is whether
>
I've just made a commit that adds an example of what I'm after in my
first "real" contribution to Jmol:
applet.getAppletInfo("atomList","")
With this addition, one can query the applet to find out which atoms are
in a particular set.
So, for example, one could query:
applet.getAppletInfo("at
> (String)getAppletInfo("fileContents") added
> (String)getAppletInfo("fileContents","") added
Bob,
Offering this functionality is fine ... but I do not think that it is
appropriate to overload the 'getAppletInfo' name.
getAppletInfo() has a specific meaning as part of the java.applet class.
>>Shravan is working on a completely independent applet that would send
>>script commands to Jmol.
>>
> OK, that's great. I look forward to hearing what the JCAMP
> subdirectory is about -- maybe that's a different applet.
> If so, then we should
> encourage an independent sourceforge project.
An
Chris, can you briefly summarize the state of the CUBIC project?
--people
--activity
--accomplishments to date (particularly in the applet display area)
--goals/timeline
Thanks
Bob Hanson
Christoph Steinbeck wrote:
peter murray-rust wrote:
At 05:01 05/02/2006, Bob Hanson wrote:
I'd be int
I'd like to focus this thread on JCAMP. But by all means start a new
thread. I'm starting to see an online conference on Jmol development
here
Bob Hanson
Christoph Steinbeck wrote:
Bob Hanson wrote:
I realize there are several people headed in this direction. My main
point is simply wh
Bob Hanson wrote:
I realize there are several people headed in this direction. My main
point is simply whether it makes sense to have such a large, completely
separate application so closely tied to Jmol.
Good point, Bob.
A question: Is this a discussion on Jmol/Spectroscopy in general or are
De: Libo Yu <[EMAIL PROTECTED]>
>
>Hi,
>
>I am investigating if it is possible to integrate JmolViewer into my Java
>program. I notice that JmolViewer accepts Ramol script on the
>commandline when being launched. After that, users have to right click the
>mouse to select command from a pop up m
peter murray-rust wrote:
At 05:01 05/02/2006, Bob Hanson wrote:
I'd be interested in hearing from shravan about plans for this JCAMP
business.
The reason I ask is that Robert Lancashire already has a Java applet
that is
pretty advanced as a JCAMP reader, and he is developing it in
conjunctio
Hi,
I am investigating if it is possible to integrate JmolViewer into my Java
program. I notice that JmolViewer accepts Ramol script on the
commandline when being launched. After that, users have to right click the
mouse to select command from a pop up menu. My question is whether JmolView
h
33 matches
Mail list logo
