Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#192 save settings on exit

Bob Hanson

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.


<< < 1 2 (Page 2 of 2)
  • Ted Cohen
    Ted Cohen

    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.

<< < 1 2 (Page 2 of 2)