Feature Requests item #3485099, was opened at 2012-02-06 13:58
Message generated for change (Comment added) made by buckyb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379136&aid=3485099&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Andriy Zhugayevych (azh4)
Assigned to: Bob Hanson (hansonr)
Summary: save settings on exit
Initial Comment:
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.
----------------------------------------------------------------------
Comment By: Ted Cohen (buckyb)
Date: 2012-02-07 20:10
Message:
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.
----------------------------------------------------------------------
Comment By: Andriy Zhugayevych (azh4)
Date: 2012-02-07 18:27
Message:
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.
----------------------------------------------------------------------
Comment By: Ted Cohen (buckyb)
Date: 2012-02-07 11:56
Message:
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.
----------------------------------------------------------------------
Comment By: Andriy Zhugayevych (azh4)
Date: 2012-02-07 10:23
Message:
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.
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2012-02-07 10:00
Message:
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.
----------------------------------------------------------------------
Comment By: Andriy Zhugayevych (azh4)
Date: 2012-02-07 09:31
Message:
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.
----------------------------------------------------------------------
Comment By: Ted Cohen (buckyb)
Date: 2012-02-07 03:31
Message:
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?
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2012-02-07 00:53
Message:
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
----------------------------------------------------------------------
Comment By: Bob Hanson (hansonr)
Date: 2012-02-06 17:18
Message:
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.
----------------------------------------------------------------------
Comment By: Andriy Zhugayevych (azh4)
Date: 2012-02-06 17:02
Message:
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.
----------------------------------------------------------------------
Comment By: Jonathan Gutow (gutow)
Date: 2012-02-06 14:33
Message:
Please make a specific list of what you would like saved. Jmol does save
many settings such as window position and such.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379136&aid=3485099&group_id=23629
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
