Thanks, Miguel. This is a good starting point, I think.
Miguel wrote:
My rule-of-thumb criteria (or wishes) are:
* Bug fixes should be isolated to 1 or 2 source files.
One would hope.
* Features should be isolated to something like 4 source files ... major
changes in 1 source file + minor edits in 3 source files.
This latter won't always be possible. In general, a new script command requires
changes to Token, Eval, Viewer, JmolConstants, Frame, ModelManager, and possibly
new classes.
I would like to add:
* All new features to be discussed and agreed upon by consensus on this list
prior to implementation.
* All commits isolated to one specific topic.
* Use of Eclipse autoformating requested at least as a starting point for all
new methods.
* No use of file-wide autoformating. Ever.
* No changes "just to clean up the formatting."
Miguel wrote:
Script related
--------------
r4507 - multiple expressions for connect and monitor
r4522 - adds radius to connect
r4551,r4555 - monitor changes
r4664,r4666 - connected() script operator + within() changes
connected() is fantastic. Please restore as implemented.
Feature related
---------------
r4504,r4506 - frame play ?? Don't mnow whether or not this involved
changes to the threading model ??
Key here is the concept of frame RANGE, which was difficult to implement
correctly. Substantial changes here to all handling of current model display and
handling of model visibility. Not sure what you mean by "threading model" in
this context, but the changes implemented are important. What is changed is not
the model, as I see it, but the way the "next frame" is selected. Please restore
this in its entirety.
r4659,r4662,r4663,r4668,r4669,r4674 - polyhedra ?? Why was an Atom
constructor introduced that creates a fake/artificial atom ??
This is necessary because the centerpoint of the "collapsed" polyhedron is not
an atom, it is a projected point from the central atom. So it has xyz and screen
coordinates only. I like your idea that "Atom" should be an extension of "Point"
and that this should be a Point.
Review post 10.1 release
========================
Applet event model + model info
-------------------------------
r4445-r4461 - getAppletInfo work - at a minimum needs a method name change
because getAppletInfo is part of java.awt.Applet public interface. Perhaps
this was replaced by some form of getProperty.
I originally introduced this as a sort of getProperty, but then in response to
your concerns changed it to the standard:
Syntax: String getAppletInfo()
Returns: String
Description: This method returns the Applet producer and copyright
I would like that functionality returned (involves Viewer functions that can
deliver this information) so that JavaScript and other apps can read the Jmol
version/date and OS information as I had set up.
r4447-r4470 - applet getProperty
this was later also introduced as a script command. That will be quite useful.
r4472 - JSON
r4475,r4476 - applet.loadLinee + getProperty
r4477,r4560,r4651 - event queuing/polling - applet synchronization
r4480,r4483 - statusManager / propertyManager
I'm looking forward to your implementation ideas here.
r4500 - scriptWait with JSON
or not -- just don't return a Java object to JavaScript. It will be a true
support headache.
r4509 - isPredefining + atomInfo
>
> r4512 - statusManager + animation + compiler define/@
(Two together.) The key here is that we have a fundamental flaw in the handling
of user-defined terms. If we allow this, which we must, then we need to allow
people to override current Tokenized terms, only warning them via System.out.
Otherwise, as we add new tokens, SOMEONE out there might have an instantly
broken page. We must reserve the right to add new tokens; we should not make
that break pages. The compromise is that introduction of a new token, in this
case "prev" for the frame business, if it conflicts with a user definition
(Otto's, as I recall), should gracefullly notify but not disallow that
overloading. Chances are the functionality introduced are not used in any
current application EXCEPT in this "define" context. Please restore.
r4516-r4519 - atomInfo + JSON
r4523,r4525 - getProperty("modelInfo")
etc., etc.
r4528 - statusManager + pmesh
The inline pmesh idea may be unnecessary now with draw; Easy enough to put in
though, and it allows for simple testing of pmesh. Not a priority
r4530 - orientationInfo change
r4531 - statusManager + propertyManager
Somewhere in there is the whole business of "state" that I introduced. Please
restore.
r4533 - refresh() in evalExpression
no longer necessary. This should be handled by the Viewer modifications that
checks model visibility, with abstraction of all unnecessary checking of states
in renderers and the addition of Atom and other class visibility flags.
r4545 - getProperty()
r4550 - viewer.script() -> viewer.evalStringQuiet()
This has to do with the App not notifying the status manager when menu items are
selected, I think.
Atom visibility
---------------
r4537,r4539,r4541,r4543,r4545,r4598,r4599 - atom visibility + tainted
critical.
transformation/spin/camera related
----------------------------------
r4586,r4587,r4591,r4593,r4606,r4608,r4610,r4627,r4633,r4638,r4650,
r4688,r4689,r4690, - spin, rotate, internal coordinates, windowCentered
This will keep you busy. :) changes we discussed on Sunday involving
Viewer.getDefaultRotationCenter() that fixes Frieda-like jumps and permanently
stabilizes model from "walking" into the camera.
Reader/File related
-------------------
r4558 - amino read
I don't think this is mine.
Featire related
---------------
r4562,r4563,r4567,r4570,r4658 - draw
This should be relatively painless. Add the classes; stitch in the
Compiler/Eval/Token/JmolConstants business.
r4614,r4621 - #jmolscript in AtomSetCollectionReader
and Spartan SMOL reader and Xyz reader and related functions;
Unknown
-------
r4655 - ? spin + compiler + bug + Float.MIN_VALUE
You'll have to look carefully at the compiler code changes there; I can't
remember specifically.
If you mean "the smallest positive number" -- something like 1E-45, then leave
it; if you mean "the most negative number" (which I think you do, in some cases)
then you want -Float.MAX_VALUE
r4685 - ? movement of code from Eval to Viewer
Actually, this is all to Frame, via Viewer and modelManager. The programming
model had been "just do atom-bitset construction in Eval" such as getNucleic()
getProtein() and such (I can't remember the exact names) even though all these
have nothing to do with scripting. I moved them to Frame and then created a
standard set of interfaces via Viewer that accessed them using just a couple of
generic functions. We need to do this because there is a general need to create
bitsets outside of the Eval framework. I'm forgetting the exact point of need,
but once one was needed, the rest naturally followed. As I did this I found a
bug in the resno/chain specification business. That needs fixing prior to 10.1.
r4529 - ? multifile not showing bonds
These are ongoing changes needed to display multiple files. It's a work in
progress. Please restore it.
Deprecated (not a complete list)
--------------------------------
r4474 - connect STATIC - deprecated
That's connect EXISTS, right?
bondorder - deprecated
I guess I'm OK with that. It does have a use, vaguely.
Other concerns Bob has
----------------------
--Your schedule is very ambitious.
--The frame business was especially tricky. It's very important functionality
but quite complex. I would like all of the model display and visibility flag
business that I introduced to be restored, as it is critical functionality and
needs very careful implementation. I think part of this is in JmolConstants.
Check the end of ModelManager for the central methods.
--The new streamlined handling of all transformations in terms of two entrant
"internal" an "fixed" methods is critical. There are important tie-ins to the
MouseManager or PickingManager (can't remember which).
--I'd like to add dipoles before 10.1. The code is all there (on my local set);
it just needs inclusion. This was discussed at the ACS meeting, and I promised
it to John Gelder. It involves three classes: Dipole, Dipoles, and
DipolesRenderer, and Eval. It's a fundamentally new class -- sort of a mix of
Rasmol-like cartoon and atom-based vector. The dipole information from Spartan
SMOL files is read and stored in atomSetCollectionAuxiliaryInfo. Spartan partial
charges are also read, and general utilities to install auxiliaryInfo into the
partialCharges array are included. Bond dipoles are calculated from partial charges.
--I'm assuming this is the full list of commits, including those prior to SVN
implemenation.
--
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
