Re: [Jmol-developers] Getting started with Jmol development

[Bob H. <ha...@st...>]

OK, Andy, I've added you as a developer. Welcome!  Your branch is

https://jmol.svn.sourceforge.net/svnroot/jmol/branches/turner-dialogs/Jmol

This is taken from Jmol 11.5.18_dev, revision 9142.

You can check that out via SVN and do anything you want with it. When 
you have something you want us to look at, either because it works or 
because you can't figure out what's wrong with it, do a COMMIT back to 
the server and give us an update on this list.

I recommend spending some time on design and passing a few ideas to us 
before you do any coding. You might get some good ideas you haven't 
thought of. One of my jobs is to ensure that what you do covers all the 
bases, so I might suggest issues relating to multiple file loading or 
file formats or the state or such.

When you do code, you can add dialogs classes directly into 
org/openscience/jmol/app. I use in Eclipse ALT-S-N a lot -- this 
reformats a method but not the whole file. If necessary use ALT-S-F to 
format the whole class file, but do this only sparingly. The key there 
is to set up Eclipse defaults to conform to what the rest of us are 
using. I can't remember off hand how to do that; Egon and Nico know. Do 
a little coding and show it to us, and we will make suggestions if we 
see format issues.

Follow the lead of the other coding you see -- UpperCaseCapitalization 
for classes, lowerCaseCapitalization for methods and variables, static 
when possible, private when possible, public only if absolutely 
necessary. (Probably none of these in your code.) There are a lot of 
useful methods in org/jmol/util. So take a look there. Also, there are a 
few public methods in org.jmol.viewer.FileManager that make file access 
easy.

Please don't refactor code outside of those dialogs you are creating. In 
addition, if you find yourself wanting to modify code in org/jmol, 
please consult me first. I'm often working on those files, and it can be 
quite a pain to merge later if we both hit the same file at the same 
time. (Actually, this isn't too bad, but it's still a pain.)

Mainly, you want to use methods in org/jmol/api/JmolViewer.java. These 
are the "safe" methods that shouldn't evolve. Most of your actions 
should probably run JmolViewer viewer.script(). Follow the lead of other 
dialogs that are part of Jmol already. If there isn't a method there 
that you think you need, then we can talk about the best way to make it 
happen.

Periodically you are going to want to do a merge from 
https://jmol.svn.sourceforge.net/svnroot/jmol/trunk/Jmol/src to update 
your branch with the trunk development branch. When that time comes, if 
you need help, just ask.

At one point or another I'll merge back from your branch to the root to 
incorporate your contributions.

That sound OK? Happy coding!

Bob


Andrew Turner wrote:

>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
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>    
>>
>
>  
>


-- 
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