On Tue, Aug 2, 2016 at 5:52 PM, Geoffrey Hutchison <geoff.hutchi...@gmail.com> wrote: > I’ve been talking with Paul Boone, an experienced Python programmer on staff > here at Pitt (and soon to be PhD student) about the Python interface to > Avo2. > > Short message - we think it's easy to add script support for a *lot* of use > cases without much work. > - Scripts could pop up an options dialog, receive a cjson molecule, and pass > back a new cjson and optionally some messages. > > Consider the case of a script (Python or not) that modifies the molecule > somehow. Maybe it scales the bonds. Maybe it generates a crystal structure… > That script probably wants an options dialog in Avogadro and then a “run” > script that passes back the modified molecule in cjson format. Avogadro adds > an undo/redo between the two structures. > > The beauty is that it's really easy to write this kind of script, either for > personal use, or to distribute and it's powerful. Imagine a "stack" script > that replicates the molecule X times along the x/y/z axis after translating > by Y Angstroms. > Sounds good. > > Much of the code we want is already there in the input generators - building > the dialog GUI. > - Except the input generators currently don’t allow floating point #s > - They don’t (always) receive the current molecule when asked to create the > input dialog JSON > - They don’t have any sort of language / localization > - They don't allow multiple tabs/panels > > My suggestion here is to refactor the InputDialog class to OptionsDialog > - Allow floating point numbers (with constraints on precision and range) > - Add a --language=en flag to the script to load different JSON depending on > the user's default language > - Always pass the molecule as CJSON (and drop the CML version) - allowing > the dialog to change based on the molecule
I think for big molecules there is value in not passing the molecule when the script won't do anything, but this seems like a simple flag in the JSON to specify whether the molecule is desired or not. > .. for example maybe showing a different interface if a unit cell is > present, or filtering basis sets based on atoms > - Add a syntax for multiple panels, e.g. > "Basic" : [ .. ], > "Advanced": [ .. ] > > I'd also suggest that to better support an "installer" feature, that we > change the scripts to live in separate directories: What would the installer feature do? It isn't clear what install means, but the package.json, and run.py etc seem to make sense. > > gaussian/ > .. run > .. install > .. package.json > qchem/ > .. run > .. install > .. package.json > > This means that while we'd encourage Python, in principal, users could write > their plugin scripts in *any* language as long as it meets the minimal API > (i.e., pass back JSON for the dialog). > This feature was designed from the start to support any language, but we never went beyond Python. The input/output is language agnostic, but there is value in knowing that this package is Python, and that we can use the Python interpreter path to run it. On Windows I don't think the executable Python stuff works at all for example, but a binary would of course work without issue. I think it totally makes sense to pull the JSON stuff into a separate file, most of what we wrote so far has no use for an install script as far as I can tell, but maybe I am missing something. I think using file endings/embedding in the JSON file the type of script would help us use the appropriate interpreter when needed. To make it easier to implement I wonder if we want to explore adding this more dynamic scripting interface as a new feature, then port the input generators if it looks general enough for them too, and allowing us to merge an earlier version that perhaps doesn't have everything working. There are also the file format scripts, that could be in any language too but are currently hardwired for Python. Slicer has some work that has gone in this direction, see the command line modules, https://www.slicer.org/slicerWiki/index.php/Documentation/4.1/Developers/Modules for some brief details. For the Tomviz project we have Python modules that are currently hardwired in the application, and we are looking at a very similar setup where these are all designed to operate on a cube using Python, SciPy, NumPy, ITK, VTK etc. They are loaded into the application's interpreter in the same memory space in the Tomviz case though, whereas Slicer has executed command line interfaces. I think this would be great, and I was hoping to find time to move our Python stuff over to this style of layout to make installation/sharing easier. We should also add support for running from home directory as well as the system paths where the application gets installed. Marcus ------------------------------------------------------------------------------ _______________________________________________ Avogadro-devel mailing list Avogadro-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/avogadro-devel
