Jmol 11.1.17 is ready for distribution, Nico. I need to take off my Jmol hat for a while now and let this shake out. This latest check-in involved a new idea -- "registering" global variable names. This allows them to be used anywhere a variable would be used.
I got terribly bogged down yesterday in trying to get the global variable businees right. If someone wants to look into that and tell me if I'm on the right track, feel free. Here's the situation: We have a class GlobalSettings that contains a number of, well, global settings. These are settings that persist between file loads (mostly). Strictly speaking, then persist until the next "initialize" command. The complications are not easy: -- Some settings (SET ...) get saved only in shape objects such as Strands. -- Some settings can be made muliple ways -- through JmolAdapter public methods, by using SET xxx ..., or by some other command, such as "vector scale x.x". What I've tried to do is make it so that as much as possible, all SET commands operate through one of the viewer methods: setBooleanProperty() setIntProperty() setFloatProperty() setStringProperty() The reason for this is that then they automatically get saved in the global hash table for variables (viewer.global.htPropertyFlags for booleans; viewer.global.htParameterValues for the others). All SET variables are now available on the left-hand side of an assignment: set bondMode or bondMode = OR etc. This is a simple compiler change that just turns "xxxx =" into "set xxxx" in all cases. So you can do some arguably strange things like: echo = top left echo "this is an echo" What this means in practice is that SET is no longer necessary. Once a variable is "registered" in one of those tables (which all 80+ SET keywords are now) it becomes available on the right-hand side of an assignment as well, and in IF statements: if (showBoundbox) .... My problem was and still is that some SET commands go straight to the shape objects themselves and store the variable there. This results in the variable becoming volatile -- when a file is loaded, all shape objects are flushed. So they never become actual state variables. I don't know exactly what the solution is for that. Where I'm leaving this is that now at least we have a full list of all the possible variables that can be set. See http://www.stolaf.edu/academics/chemapps/jmol/docs/?ver=11.1#table1 If my count is right, I count 122 such variables. I realize that some are not documented. I have to leave it at that for now; most of the undocumented ones can be figured out from their name, I think. Anyway, this is where I'm leaving it for now. Let's see how it goes. Some are quite interesting. For example: stereo on stereoDegrees = 5 stereoDegrees = -5 etc. And I see that the list needs checking. For example, it seems to suggest you should be able to do: x = frank; but you cannot do that. So that needs some work. I think all it is is that Jmol is failing to check known token words like "frank" and "history" as variables. Bob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
