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 Sivananthan Lab_LOGO 08JAN2010 small Sivananthan Laboratories, Inc. 590 Territorial Drive Ste H Bolingbrook, IL 60440 630.226.0080 630.226.0081 Fax The contents of this email and any attachments are the proprietary property of Sivananthan LaboratoriesR. The information contained within is confidential and should not be shared, sold, or distributed without explicit permission of Sivananthan LaboratoriesR. ---------------------------------------------------------------------------- -- 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
<<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
