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 >>>> >>>> >>>> >>>> >>> >>> >> >> > > -- ================================== Dr Andrew R. Turner Research Computing Officer e: [EMAIL PROTECTED] t: +44 (0)131 650 7748 w: http://www.eastchem.ac.uk/rcf icq: 370-899-715 p: School of Chemistry University of Edinburgh EH9 3JJ ================================== ------------------------------------------------------------------------- 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
