Sorry, forgot to include it! It is 'atrog'. Andy
Bob Hanson wrote: > 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > -- ================================== 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
