Any script executed in an instance, also runs in other instances, through my
application where the Jmol is embedded.

 

But events generated by the mouse (for example) does not generate scripts.

The parameters passed to notifyCallBask in this case are all integers. How
to run it in other instances?

 

De: Robert Hanson [mailto:[email protected]] 
Enviada em: terça-feira, 9 de março de 2010 17:34
Para: [email protected]
Assunto: Re: [Jmol-developers] RES: RES: RES: Intercepting events

 

So please tell us what you are seeing now. How much is working?

On Tue, Mar 9, 2010 at 11:02 AM, Moacyr Francischetti Corrêa
<[email protected]> wrote:

Nice! It works very well!!!

 

But now I have another problem: how to process a CALLBACK_CLICK (or another
CALLBACK_XXXX) in the second intance (the instance that received the message
through my application)?

 

[]’s

Moacyr

 

De: Robert Hanson [mailto:[email protected]] 
Enviada em: terça-feira, 9 de março de 2010 01:17


Para: [email protected]

Assunto: Re: [Jmol-developers] RES: RES: Intercepting events

 

Oh, I see, then there are no changes at all to Jmol that you need to do.
It's trivial:

a) You should already be intercepting the CALLBACK_SYNC  messages. That's
what they are for.

b) The messages are simple strings that are the second element of an
Object[] array parameter "data" passed to the
JmolStatusListener.notifyCallback method. Just pass them on to the other
application using something like

  sendScriptOverTheNet((String) data[1],  "~");

c) Make sure that the second application is prepared to accept them using

  viewer.syncScript("slave", "~");

This tells that application know that scripts will be coming and to process
them but not pass them on and also to not initiate new messages. 

If you want this to be a two-way street, then change "slave" to "on". Then
the applications can talk to each other in a two-way conversation.

Likewise, of course, the first application needs to be set to "on" in order
for the system to activate, and you must include CALLBACK_SYNC on your list
of enabled callbacks for which you are going to do that in any application
that is going to be a "driver". 

Your JmolStatusListener should look something like this:

  class MyStatusListener implements JmolStatusListener {

    public boolean notifyEnabled(int type) {
      switch (type) {
         ...
      case JmolConstants.CALLBACK_SYNC:
        return true;
        ...
      }
      return false;
    }

    public void notifyCallback(int type, Object[] data) {
      switch (type) {
        ...
      case JmolConstants.CALLBACK_SYNC:
        sendScriptOverTheNet((String) data[1]);
        return;
       ...
      }

 }

On the receiving end, you just need something like

  synchronized public void syncScript(String script) {
    viewer.syncScript(script, "~");
  }


Sounds like you have all the rest you need.

Bob

On Sat, Mar 6, 2010 at 12:38 PM, Moacyr Francischetti Corrêa
<[email protected]> wrote:

Thank you for your reply, Bob!

 

The situation is as follows:

 

I developed an application with Jmol embedded in it.

In this application I get messages sent by Jmol through notifyCallback
function.

This same application sends the messages through the network to another
instance. The second instance of the application receives the messages
correctly.

Therefore, different instances of Jmol not talk to each other; the exchange
of messages is made by the application that I developed, using a protocol
specifically designed for such communication..

My difficulty lies in this: what do I do with these messages in the second
instance of my application? I have to update the Jmol incorporated into it
and I do not know how.

 

[]’s

Moacyr

 

De: Robert Hanson [mailto:[email protected]] 
Enviada em: sábado, 6 de março de 2010 11:02


Para: [email protected]

Assunto: Re: [Jmol-developers] RES: Intercepting events

 

Looking back at this, I have some of my answers to questions posed just now.

I don't think you can use the Jmol application without modification to do
this. What you need to do is build your own application that has Jmol
embedded in it, or you need to adapt Jmol to report its status over an
internet port. You could use the Jmol application or the signed applet. I
would STRONGLY recommend using the signed applet. 

Let's assume you can get a version of Jmol set up that can report its status
over an internet port. (An example of this is how the signed applet uses
internet ports to get information from a multi-touch screen driver.)

Then what you would do would be to enable syncCallback and have your
application process that. If you use the applet, this is trivial -- Jmol
already will send syncCallbacks to a web page. You could just use AJAX to
send those on to the other machine. Almost trivial.

There are two types of sync -- script and mouse. 

Script synchronization sends all the scripts executed by the user to the
other process. 
Mouse synchronization sends all user mouse actions to the other process. 

You can enable these independently. 
See http://chemapps.stolaf.edu/jmol/docs/examples-11/sync2.htm for example
of how you do this with applets. 

The way the applet does this is by a direct connection with the other applet
through

            app.syncScript(script);

which is just:

  synchronized public void syncScript(String script) {
    viewer.syncScript(script, "~");
  }


That is, Jmol takes care of everything for you. When the user issues a
script command or uses the mouse, Jmol creates the proper string that
encodes this information. It then passes the string on to the other process.


All you would have to do is set up an internet port based communication
pathway between the two applets or the two Jmol applications. (Personally, I
would use signed applets, not the application. Then you could fit around
that all the video, chat, etc. links that you want.) 
 
Just set up a syncCallback (which intercepts those messages) and then send
that sync message to the other machine. 

A great project I just have not had time to work on myself. 

Does that help?

Bob





-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900


----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900


----------------------------------------------------------------------------
--
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get. 

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to