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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

The difficult thing will be that the applications will not be exactly
synchronized. For example, if you start spinning on one, spinning will start
on the other, but when you STOP spinning on one, it will not necessarily be
exactly at the time you stop spinning on the other. So realize that that is
a general limitation.

Are you setting this up so that one is a driver and the other is a slave, or
are they both drivers? Can people on both ends of the line manipulate the
model?

On Tue, Mar 9, 2010 at 2:33 PM, Robert Hanson <ha...@st...> wrote:

> 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 <
> mo...@sp...> 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:ha...@st...]
>> *Enviada em:* terça-feira, 9 de março de 2010 01:17
>>
>> *Para:* jmo...@li...
>> *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 <
>> mo...@sp...> 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:ha...@st...]
>> *Enviada em:* sábado, 6 de março de 2010 11:02
>>
>>
>> *Para:* jmo...@li...
>>
>> *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
>> Jmo...@li...
>> 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
>> Jmo...@li...
>> 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
>

-- 
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

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

An interactive viewer for three-dimensional chemical structures.

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