Jonathan Gutow wrote: > Most of the issues relate to the user interface I'm trying to > generate. For example, to have clean control of the axes they've > drawn from the user interface draw items need to have labels. Sage > Worksheets created so far don't name draw items in scripts, so I have > to make some assumptions. Another example is that as we fix bugs or > enhance things they don't work exactly as they once did. I already > pointed out that there was an issue with the angle of frontlit between > 11.6 and 11.8, which is obvious when playing with simple SAGE > surfaces. I've worked around that in my code by issuing a pmesh o* > fullylit command. But this depends on the fact that presently SAGE > names all the surfaces obj_XXXXXXX. Anyway, I expect issues like this > to continue. I also find it very hard to build a web interface based > on a moving set of features, so I'm playing with the 11.9 features, > but expect the next version of Jmol in SAGE to be 11.8 (I hope very > soon) and want to be ready to put 11.10 in when it comes out. I'd > like to see that include a plot primitive. > >
Jonathan: you probably already know this, or are past the point where this is helpful, but a while ago I posted a Sage package for jmol 11.8.6: http://trac.sagemath.org/sage_trac/ticket/7003 > Since Jason is lurking here too maybe he can add to the following list > of what it might contain. My preliminary thoughts are a structure > that contains: > > 1) An arbitrary number of isosurfaces, with attributes color, > transparency, visibility, mesh color, mesh visibility, lighting state > (fullylit default). The range for the numbers in these isosurfaces > should be limited only by the number range available for floating point. > 2) Strings to title the X, Y and Z axes > 3) Based on the range of the isosurfaces (pmeshes) provided Jmol would > determine the bounding box and the scale adjustment for display. > 4) This structure would have scriptable functions for turning on and > off each of the edges of the bounding box, the axis titles and > automatically computed numerical ranges on the axes (a real bonus > would be if the tick numbers could be associated with any of four > equivalent axes). I think the SAGE solution of a minimum of 3 numbers > per axis is pretty good. Really big displays (> 600 px square) could > benefit from 5 numbers per axis. > Things related to axes/bounding boxes that come to mind (possibly covered in what you said above) are: * a way specify tick locations for each axis (in addition to the option of jmol doing things automatically) * a way to specify formats for tick values (e.g., "%.3f", or whatever is easiest for you guys to parse and use) * a way to specify just a list of tick labels (so we could do a tick labeled "pi", for example) * a way to turn on and off axes that meet at the origin and the bounding boxes, independently. (this is already possible, I'm pretty sure) * Axes that meet at the origin having tickmarks too. > So ideally SAGE can just generate an unscaled list of isosurfaces, > planes, etc.. Then Jmol would worry about making the plot pretty. > That would be great and would clean up the code right now that does scaling, etc., before things ever get to jmol. It would also allow us to more easily use things like picking in jmol, which I think is messed up right now since we scale everything before it gets to jmol. Thanks, Jason ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
