what's your SourceForge user name? Andrew Turner wrote:
>Hi Bob, > >OK. Give me a branch and I will see what I can come up with. > >Cheers > >Andy > >Bob Hanson wrote: > > >>Andrew Turner wrote: >> >> >> >>>Hi >>> >>>Bob, thanks for the pointers they are really useful. >>> >>>I work at the University of Edinburgh trying to get experimental >>>research chemists to use computational chemistry tools. Not just as >>>collaboration, but teaching them to use then so it becomes second nature >>>in their research (like getting an NMR spectrum or running MS analysis). >>>Part of this consists of finding tools that are easy for them to use (on >>>whatever platform) for building input, submitting calculations and >>>analysing output. >>> >>>My ideas for contributions reflect my user base and are mainly on the >>>application side I guess. Things I would like to add: >>> >>>* A save molecule dialog that can write the system in a variety of >>>formats. Some coordinate types but also input for common codes that we >>>use (Gaussian, MOLPRO, Castep, CPMD). There may be a role for Babel >>>here. It might also need different dialogs to deal with different codes. >>> >>> >>> >>> >>Very nice idea. It would be based on the current WRITE command, which >>allows saving of atoms in XYZ, MOL, or PDB formats. It has the nice >>feature that it can extract out just those atoms selected. >> >>My programming strategy has been to make every action of a dialog >>reducible to a script command. That way there is basically nothing that >>can't be done by scripting. So if we, say, develop a new format for >>output, what we would also do is create a WRITE command option for it >>and run it through that command. It takes a bit of coordination to get >>that all to work, but I think it's worth it to have everything going >>through the script processor (Eval/Compiler). This also makes possible >>automated batch processing, because scripts can be run from the Jmol >>application command line in batch mode. >> >> >> >>>* A dialog for controlling the plotting of surfaces from cube files. >>>Pretty simple initially but moving on to handling mapping and slices. >>> >>> >>> >>> >>That could be very nice. It would generate ISOSURFACE commands >>consistent with the user's settings. It should not depend on the data >>being from a CUBE file -- Jmol basically constructs cube-like >>"volumetric" data from all sorts of sources now. These include molecular >>orbital coefficient/basis data in the input file, partial charge data >>either from the input file or supplied separately, molecular surface >>calculation, and even user-supplied f(x,y) data. >> >>One of the very nice capabilities of Jmol is to then take that surface >>and create a JVXL file -- a very compact encapsulation of one or more >>specific surfaces selected by the user based on the much larger CUBE >>data set. >>So that would be nice to have as part of that dialog. >> >> >> >>>* An interface to Globus Toolkit for submitting jobs using UK e-Science >>>certificates. We are developing a Gaussian submission portlet and would >>>like to use the Jmol applet within it for viewing input and output, it >>>would be nice if we could integrate the submission into the Jmol >>>application. >>> >>> >>> >>> >>Could this be web-based? So that it is the applet the user is using? Or >>do you see it as being the application? This sounds much like WebMO. >>Have you taken a look at that? It's very popular around here. >> >> >> >>>I have had a quick look through the feature enhancements on the wiki and >>>cannot see these things. But please correct me if people are already >>>working on them. >>> >>> >>> >>> >>> >>The dialog idea is terrific. So that's probably the application we are >>talking about there. Because the applet more generally just uses HTML/JS >>buttons and such. That way the user interface is entirely flexible and >>customizable. >> >>The truth is, the Jmol application has not had the sort of scrutiny or >>general use as the applet. BUT it is precisely this sort of development >>that will make the application more useful. So I certainly support >>everything you have suggested there. Basically, my routine is to do all >>development on the application, being careful to consider what aspects >>are application-only (in org.openscience.jmol.app) and what is common to >>both applet and application (in org.jmol). (There's also some code that >>is applet-only; it goes into org.jmol.applet, and it is delivered with >>Jmol.jar even though not accessible through it.) >> >>Jmol is also integrated into all sorts of other programs, so we provide >>the JmolViewer interface as a simple way of getting core information out >>of or into Viewer. Viewer itself is also public, so one does not HAVE to >>use JmolViewer, but I'm sworn to not adjust the signatures of those >>methods in JmolViewer, while the Viewer signatures are fair game for me >>to adjust as needed for the internal operation of the Viewer. >> >>Let me know when you want to get started, and I will create a branch for >>you and enable your access as a developer if you don't have it already. >>Sounds wonderful. >> >>Bob >> >> >> >> >>>Regards >>> >>>Andy >>> >>> >>> >>>Bob Hanson wrote: >>> >>> >>> >>> >>>>Andy, welcome aboard! Tell us about yourself. >>>> >>>>I'm probably the only one right now who really knows everything that is >>>>in the code and how it works. So ask me anything. One thing you can look >>>>at is the viewer.gif file in >>>>http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/org/jmol/_documents/ >>>> >>>>It's a bit out of date, but it shows the basics of how the different >>>>classes are related. Primarily, Viewer is the key player here, and all >>>>the "managers" work with it. >>>> >>>>In answer to your specific question, the script goes into a queue and is >>>>processed within the ScriptManager class. When its turn comes up, it is >>>>sent to Viewer.evalStringWaitStatus, where it is then sent to Eval for >>>>processing. Eval passes the script to Compiler for compiling and some >>>>syntax error checking, after which it takes the form of a set of >>>>commands, each of which consists of a Token[] array. There are some >>>>replacements that go on late in the game, and the result is a Token >>>>array called "statement". This is the currently processing command in >>>>token form. The main loop in Eval is the method instructionDispatchLoop. >>>> >>>>If you are interested in contributing, that's great. We can set up a >>>>branch for you, and you can play all you want, letting us know if you >>>>are having success or problems. If something looks good, we'll merge it >>>>into 11.5, which is the trunk for current development. I recommend not >>>>doing major code refactoring or modifications without first checking >>>>with this list to see if it would make merging too difficult. >>>> >>>>What sort of ideas are you thinking of in terms of contributions? >>>> >>>>Bob >>>> >>>> >>>>Andrew Turner wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>I am new to developing Jmol and have a few ideas as to what I could >>>>>contribute. I have been to the Jmol wiki and checked out the Jmol source >>>>>into eclipse. >>>>> >>>>>My question is this, is there anywhere that provides a overview of how >>>>>the Jmol package fits together. I have had a look through the source for >>>>>a few hours and feel I am no closer to understanding which bits do what. >>>>> >>>>>For example, if I type 'write COORD "file.xyz"' in the scripting dialog >>>>>of the application, where does the final file writing actually get done. >>>>>I can trace the command to Viewer.evalStringQuiet but start to get lost >>>>>pretty soon after that. >>>>> >>>>>If anyone has anything useful I would be glad to see it. >>>>> >>>>>Regards >>>>> >>>>>Andy >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
