Rene wrote: > I think I am about as far as I can get with the AtomSetChooser. > I moved it over to the Tools menu where it fits better.
Agreed > Some issues I encountered, relating to the JmolViewer: > > 1) settting a radius of 0.01 makes the vectors fat. Not sure why. (You > can see this when you do it in a script too). This is because vectors follow a different rule for how sizes are handled. Small integer values for vectors actually specify pixel count, not angstroms. So when you are saying .01 this is getting converted into 10/1000 = 10 pixels. If you want to make the vectors small you can say vector 1 > 2) certain 'set' methods do not update the display, e.g., > setDisplayModelIndex(int), setVectorScale(float), so I reverted back to > the evalStringQuiet(string) way of executing a script command in stead. Hmmm ... yes ... that is a problem. I didn't want these 'low level' routines to be initiating lots of screen repaints. The assumption was that if you were using these routines then you could tell the viewer when to trigger a repaint. Certainly, everything is easier if you just call the script evaluation code. > 3) the 'play' button in the collection area (the top of the two VCR > type controllers) uses the script method of doing a slideshow. It turns > out that the loop at the end seems to take a while so that you play to > the end of the scrip, and get a 'pause' before it starts over again. I put explicit delays of one second at the beginning and end of the script commands. You can control this by specifying 'anim mode loop 0 0' which says to wait 0 seconds at the beginning and 0 seconds at the end of the loop. > Also the interactivity of turning the molecule while it is playing like > that is not particularly good. I don't think it has anything to do with scripting ... you are just working your machine too hard. > So maybe I am asking you to provide a > more flexible JmolViewer.animate(int AtomSetIndexes[], int startIndex) > to do something similar to what I am doing now. OK, we'll see. I think your control panel looks *very* nice. I think that you need controls for 'looping' on animations. > 4) It would also be nice for me to be able to find out which modelIndex > is currently shown (so I can make the slider go to the proper location > as opposed to having to back to the first in the collection). > > I chickened out about the visual update of the selection in the tree > during any kind of playing through a selection of atomsets, or > 'sliding' through them. My excuses are: > > 1) a bit tricky to implement (so as to not fire events in succession > and getting into a loop of events). > > 2) One could consider the tree as way to select a collection of > atomsets (i.e., for a branch: all the children, for a child: all its > siblings) so that the 'first'/'last' etc sliders work within that > collection (which may not have sequential atom set indices). So in that > respect, the selection would not change when one is 'sliding' or > playing through them. These are very good excuses ;-) The problem is that during an animation we don't want to be updating too much UI. I think it is more important that the animation/slide show/vibration run smoothly. Perhaps you want to grey out the slider during an animation. During single-stepping you could update the slider. There is currently an animation frame callback that should be being called. But, on second thought, maybe it is not being called for a slideshow. Miguel ----- Open Source Molecular Visualization www.jmol.org [EMAIL PROTECTED] ----- ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
