Menu
▾
▴
#192 save settings on exit
Most of GUI-equipped programs save their settings on exit (e.g. color or rendering scheme). May we have such feature in Jmol application?
More specifically two commands need to be implemented: 1) enable/disable "Save settings on exit", 2) "Restore default settings".
Additionally it would be convenient to have the fast route to load the frequently used user scripts (for example to change program settings). This feature can be included into existing "Open" command by adding the link to some fixed user folder where the user can keep its scripts. However I would add additional button. This feature would mimic Style Manager in Mercury program.
Please make a specific list of what you would like saved. Jmol does save many settings such as window position and such.
1) Style/Labels
2) Color/Labels
3) Color/Background
4) Style/Unit cell, Style/Axes
5) Style/Scheme
Also I would save "Style/Atoms/Show hydrogens" but this may puzzle unexperienced users.
That's a tough one. Clearly you can save whatever styles you want if you know a bit of scripting, but you want it to be more accessible than that, I think. The problem is that styles for atoms and bonds, labels, unit cells, and axes are all reset after a model is loaded. They aren't program-session specific. The only exception to that is when you color an element. That one carries over between models.
Edit...Preferences allows some of this -- you can set preferences for atoms and bonds at least.
So I suppose we could add a few more options to that.
I think this is arguable. DIfferent structures will need totally different "styles", I don't see it clear that any preference will be applicable to everything.
Anyway, there is the "macro" feature taht you can use to quickly set your styles. Maybe that suits yor needs. And there is indeed a user fiolder (precisely where thiose macros are put).
http://wiki.jmol.org/index.php/Macro
Please correct me if I have this wrong, but I thought that the output of the various "show" commands could be saved by the user and then "played back" unchanged to restore the state to what it was. Could one not issue a "show state" command and write the contents to a file when unloading an instance of Jmol and then restoring it on the next load. It seems that there would be a lot of ambiquities for Jmol to try to resolve if Jmol tried to do a "one size fits all" solution. For example, you may have multiple apps that use Jmol on a machine and a user may want to keep a seperate set of preferences for each app. Or there might be several users that share a work station in a lab and each user may want his preferences saved seperately from other users. By writing the save/restore script yourself as Bob suggested in the second comment, you can get exactly what you want using existing features of Jmol. For example you could save state in a different file for each user or for each app if that is what you needed. A few questions that I have: When is the unload callback called? I am hoping that it is the inverse of the onload callback. That is the the onload callback is called last, after everything else is done and that the unload callback would be first, before anything is torn down. Hopefully, that would allow the user to issue a "show state" from the unload callback, get the state and save it somewhere. Secondly, is the unload callback called at all in the standalone version or only in the applet version? I am suspecting that Andriy's request is for the standalone product rather than the applet. Is there a way for a user script to get control on exit in the standalone? In the applet version, could the user store state in the unload callback or is the state already lost by the time the callback is invoked?
Thank you for suggestions.
1) Macro solution looks fine, but the described on http://wiki.jmol.org/index.php/Macro algorithm does not work for me: when I press Macros menu nothing happens (I have Jmol 12.2 on Windows 7).
2) Script solution looks also fine, but to load a script from $HOME/.jmol directory I need at least 5 clicks.
3) Save state solution is file-dependent.
Bottom line: in the view of "Interface Improvements" Category the above solutions are unsatisfactory. I remind my main point: most of GUI-equipped programs handle user settings in a multiuser environment in a user-friendly way. And I don't see the reason why Jmol application must stand as an exclusion. Jmol is not "as is" program but one of the leading (and currently the most universal) tool for visualizing molecular structures.
Hi Andriy
Another hint:
http://chemapps.stolaf.edu/jmol/docs/#set_defaultloadscript
If the macro is not working, we should wrk on it. I haven't used it lately but it did work; maybe the instructions are not good. Could you please follow this up and give details on the jmol-developers or jmol-users email lists? That is easier to discuss than thi bug tracking system.
Thank you, set_defaultloadscript and any other solutions based on loading a script with starting Jmol application, together with the mentioned previously macro/script possibilities do not provide the solution to the posted problem: save current settings on exit. They just provide the way around the problem.
We just went through a process to select a chemical visualization tool. The very thing that Andriy describes as a weakness in Jmol, was the reason that we selected it. If I can explain using a poor metaphor, Jmol is like a cobler kit and using it, you can build any size shoe that you want. Andriy is saying I wear size 9 shoes and so do a lot of other people so Jmol should come prebuilt for size 9. I gave two examples that his simplistic request did not address (multiple Jmol users on one computer and multiple Jmol consuming applications on one computer). I feel that in order to give additional consideration to the feature request Andriy needs to propose a solution that addresses the issues that I raised as well as the implicit issue that Jonathan raised which is that his list won't satisfy all users of Jmol. I don't think anyone is opposed in concept to the request. It is more "how can this request be implemented in a general way that works for all Jmol users". It is hard to give it enthusiastic support until that becomes clear.
To address some of Anriy's recent points. He does not like the "show state" solution because it is file dependant. If we don't save state in files between executions of Jmol, where do we save it? He also objects to the 5 clicks to load a script but the answer to that, I thought was implicit. You build your own app, around Jmol. You don't start Jmol itself but rather your own app which invokes Jmol and feeds it the state that you saved upon last exit. When Jmol exits again, your app grab the current state and stores it. No extra clicks are required, just some programming time to build your shoe, using the cobler kit provided by Jmol, just the way you want it.
In our selection process, we saw lots of applications for visualizing chemical models but we passed on them because we could not customize them and we could not include them in our own application. If a prebuilt viewer that saves and restores state is needed, they exist but I would guess that Andriy does not go that direction because Jmol provides more "power". Jmols power comes from the fact that it does not rope you into any one predefined way that things must be done. Jmol gives you the power to have the things the way that you want them instead of the way that someone else wants them, but it comes with the price tag that you have to roll up your sleeves and do some of the work yourself which in this case is to build the wrapper to save and restore, just what you want, just where you want it, using the tools already provided. If there is any state element that can't be saved or restored with current tools, based on what I have seen, Bob would have it in the next release of Jmol.
It's much more easier for an experienced user like Ted to press "Disable Save settings on exit" command than for an average user like me to implement Ted's suggestions.
I am not an experianced Jmol User, I am not even a Jmol user at all. I am a computer programmer. I was hired on 12-27-2011 to pick a rendering technology and fold it into a chemical library at a research institution. I completed the project on 1-31-2012 only because of the great work in design and execution of Jmol by Bob, Angel, Jonathan and about four other people. The message that I am trying to bring across is that what you are asking for, while it seems trivial to you, is not trivial to implement due to the nature and power of Jmol and while I have only briefly touched on this, in response to your other open feature request ("buttons for frequently used commands") the people that have created Jmol for you have families and full time jobs. Jmol work is unpaid so even if we have a great need and a great design, who is going to write the code and when? I thought the I might be able to code your button request. I downloaded the source for Jmol and started looking through it to see about implementing it. But this request is not well thought out. We do not yet have a good design in my mind. I was asking you to come forward, think about the issues that Bob, Angel, Jonathan and myself raised and participate in bringing forth a design that works for all Jmol users. (As I read that stats, Jmol averages 8,000 new users each month!) Once a design has been worked out, then it is a matter of finding someone to write the code which is another matter entirely. Your unwillingness as a user to "customize" Jmol has me concerned. I proposed a solution to your button request where any user could create their own, customized list of buttons. Are you really unwilling to make your own list? Do you really want the Jmol team to take the list you provided and force thousands of users to use that list? It seems to me, that at the least, you would need to create your button list and put it in the directory that Jmol loads from. If you are willing to do that, then I have a suggestion for your "restore last state" feature request. It only addresses Jonathan's question of which variables to we restore to last and which variables do we initialize to default values. The proposal would be a three level initialization. Jmol would have default values built in. If the variable is not over-ridden from one of the following two methods, it would be initialized to the built in value. There would be a custom file in a known location, for example the location where the jar files are kept. In it would be a static list of state variables. The user would intialize variables here when he did not like the default values provided by Jmol. Everytime Jmol initializes, the variables defined in this file would be set to the values in this file which would override the built in values. The third file would contain persistant state variables. The file would be rewritten each time jmol closed with the current values of those variables at the time of exit so that when Jmol loads again, those values would begin where they left off. If a variable is initalized in both the static and persistant file, I am indifferent as to which should take precidence. A warning should probably be written to the Jmol console in that case so that the user can remove the ambiquity. This only resolves Jonathan's querey of "what" variables should be saved/restored but it does not address the question of what if two users use Jmol from the same machine and they keep overlaying each others "favorites" or "preferences" or "last state" and it does not deal with the issue when using Jmol for multiple applications on one computer. I just implemented a very cool app for a researcher in Denmark that allows him to position a molecule on a surface using Jmol and then graph results that are meaningful to him. It seems to me like embedding Jmol in an instrument. I could see having dozens of such "instruments" on one computer and not wanting the last state from one being loaded as the starting state of another. I think that a well thought out design needs to forsee uses such as this and accodate it. I am not against either request, I am asking that you think through the save/restore request and design a way to do it that works for all users in all situations. Personally, I think that has to be done before one could consider allocating resources to do it. Otherwise code gets messy and hard to maintain.
In my both requests I pose my opinion on interface improvement for all users. Additional buttons and keyboard shortcuts will definitely help the most of users in the most of situations. Save settings capability will definitely not complicate the using of Jmol application for all users and will definitely help many users in many situations. My argument is simple: if most of the other programs have some capability (rich toolbars and user settings management) than it is worth implementing in Jmol. Now you decide if it is worth to put your time for the implementation. I don't know Jmol from inside to help in programming but can participate in designing.