From: Jonathan G. <gu...@uw...> - 2011-10-30 20:26:18
|
Bob, This looks like a good idea to me. As I've been working with Sage, which is python based, I have some ideas about how that might work. It might also change the way Jmol can be used by Sage, although I'm not sure there is too much they would want to change about the way it is used as a 3-D viewer. This is something I would like to work on. However, because of the way the Univ. of Wisc. System is going, the only way I am going to get to devote adequate time to it, is if I can get funded to work on it. I also think this is a project which I could get some of my CS colleagues interested in. I'm game, but as you've said, we would have to assemble a team and a pretty careful plan about how we would start this. Maybe the first step is to assemble a team to write a grant proposal or proposals? We could target national funding agencies (maybe the international collaboration angle as well?) and maybe Google Summer of Code grants to fund some students? Jonathan On Oct 30, 2011, at 5:27 AM, Robert Hanson wrote: > What do you think of writing a Python interface to Jmol? > > It seems to me a lot of people like to use Python. It's the programming language of the average scientist. Now that we have Jmol set up with a sockets interface (Molecular Playground), why not write an interface that would be the entire JmolViewer interface, but via sockets? And then write a Python (or whatever language) API to go along with it? The Python developer would simply add the Jmol.py toolkit along with Jmol.jar and have instant access to (any number of) viewers, a POV-ray generator, a molecular structure analysis engine, structure and surface file readers, callback mechanisms, a customizable interface (possibly even using the signed applet with a local HTML page), the option to run "headless" with no visible viewer, etc., etc. > > From a Python viewpoint, it would be just another package. Jmol.py would work something like a database -- you make a connection, configure the connection, make function calls ("queries"), get results -- and the API would handle all the connectivity via sockets. > > From a Jmol viewpoint, it would look like Jmol just turned into a Python version. > > In effect, rather than writing a PyMol plug-in, what Python developer/user would be doing would be writing a Python program with a Jmol plug-in. Heck, we might even be able to write a PyMol-Jmol API that would enable PyMol plug-ins to be directly adaptable to Jmol, but of course with all the added power, breadth, and flexibility of Jmol. Sort of like the way we were able to port virtually all of Rasmol/Chime capability to Jmol and extend that immensely. (But I would consider that a secondary goal.) > > Good idea? Anyone want to work on this? I would definitely want to assemble a team to do this -- I personally have no experience at all with Python. Might even be fundable. > > :) > > Bob > > > -- > Robert M. Hanson > Professor of Chemistry > St. Olaf College > 1520 St. Olaf Ave. > Northfield, MN 55057 > http://www.stolaf.edu/people/hansonr > phone: 507-786-3107 > > > 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 > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers Dr. Jonathan H. Gutow Chemistry Department gu...@uw... UW-Oshkosh Office: 920-424-1326 800 Algoma Boulevard FAX:920-424-2042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow |