Try what is up as http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.14_2014.04.08b.zip and tell me what you think.
What exactly are you doing? Are you somehow running Jmol.jar remotely instead of on your own machine? There is no "client/server" aspect to Jmol.jar that I am aware of. Anyway, I'm hoping 500 ms is long enough to prevent what you are seeing. Who holds a button down for half a second? Bob On Tue, Apr 8, 2014 at 9:05 PM, Anthony Ciani <[email protected]>wrote: > I mean that there is enough delay within the network that there could be > two or more seconds between the Jmol running on the server polling the > button press on the client, updating the display, and then polling the > button release. > > > > Yes, running an X11 program over the WAN is a very slow interface. > Although it is also generally better to use the frame command than the > increment/decrement buttons over such a slow display. > > > > I was basing the 1.0 second delay on the number of frames that typically > passed in a single click with the 100 ms timeout. On the Windows box, 1 > click was generally advancing 6 or 7 frames, sometimes 9. If I quickly > slapped the mouse button, I averaged around 1.5 frames. > > > > *From:* Robert Hanson [mailto:[email protected]] > *Sent:* Tuesday, April 08, 2014 6:31 PM > *To:* [email protected] > *Subject:* Re: [Jmol-users] Frame Next and Previous Buttons Sticky > > > > Not sure what you mean by "button response in 2 seconds" -- it's a button. > It responds immediately. I'll get a version up with the 0.5-second delay > and see what you think. It's not supposed to be fancy. Just a small > convenience and preferably not a nuisance. > > > > On Tue, Apr 8, 2014 at 5:12 PM, Anthony Ciani <[email protected]> > wrote: > > A variable would be best if you want to allow quick animation using the > toolbar. > > > > Perhaps between the Frame Previous and Frame Next buttons, place a 4-digit > wide input or pull down box to specify delays between 0 (default) and > 9999-ms, or maybe 0 to 5000 in steps of 50? > > > > Although the proposed press-and-hold (I would go for 1 second delay) > change is better than the current click-and-race, I would prefer one click > = one frame, until you can make it user selectable. I use Jmol across a > large number of platforms and network types, often to check on the progress > of very large MD simulations. Over some networks, even a timeout of 10.0 > sec could skip frames (although button response is usually under two > seconds). > > > > > > > > > > *From:* Robert Hanson [mailto:[email protected]] > *Sent:* Tuesday, April 08, 2014 12:23 AM > > It's a 100-ms repeating timeout. > > @Override > public void mousePressed(MouseEvent e) { > vwr.evalStringQuiet(script); > vwr.evalStringQuiet("timeout '__animBtn' -100 \"" + script + "\""); > } > > @Override > public void mouseReleased(MouseEvent e) { > vwr.evalStringQuiet("timeout '__animBtn' OFF"); > } > > I suppose we could set that to 200 ms or, better, a variable. > > Bob > > > > > > On Mon, Apr 7, 2014 at 5:12 PM, Anthony Ciani <[email protected]> > wrote: > > Dear Jmol Users, > > > > The Frame Next and Frame Previous buttons seem to have become sticky. > They continually advance (or recede) frames until the mouse button is > released or the mouse is moved off of the icon. Behavior is seen on > Windows, Linux (remote and local Xserv), different Java versions. > > > > I could see this being a desirable feature, for example, if someone wanted > an easy way to animate frames, but frames are updated so rapidly that a > single mouse tap could do 4 or 5 frames. On a slow display interface (e.g. > X11 over a local network), dozens of frames might be updated, slowly, after > a single click. The situation is almost unbearable if used over a slow > network. If "Animate Forward" and "Animate Backward" buttons are desired, > they should be separate on the menu bar, along with a Frame Rate box. > > > > This "feature" seems to have been present since 13.0.1. I did some > searching and found a couple messages about it, but nothing happened. The > frame command inside the console works as expected. It is only the buttons > that have become sticky. > > > > > > > > > > *Anthony Ciani* > > *Postdoctoral Fellow* > > [image: Sivananthan Lab_LOGO 08JAN2010 small] > > *Sivananthan Laboratories, Inc.* > > *590 Territorial Drive Ste H* > > *Bolingbrook, IL 60440* > > *630.226.0080 <630.226.0080>* > > *630.226.0081 <630.226.0081> Fax* > > > > The contents of this email and any attachments are the proprietary > property of Sivananthan Laboratories(R). The information contained within is > confidential and should not be shared, sold, or distributed without > explicit permission of Sivananthan Laboratories(R). > > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > -- > > Robert M. Hanson > Larson-Anderson Professor of Chemistry > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > 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 > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > -- > > Robert M. Hanson > Larson-Anderson Professor of Chemistry > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > 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 > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr 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
<<inline: image001.jpg>>
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
