Dear Geoff,
I hope it’s o.k. for me to pipe up here, but I just thought it might be
helpful if I mentioned a few things that we’ve had to think about in
our work with the ccp1gui project, and that might be relevant to your
considerations.
Geoffrey Hutchison wrote:
I’ve been doing some research on what needs to happen to allow
scripting support inside Avogadro. This would eventually allow
plugins to be written in Python or Ruby. Users could also add scripts
and an optional scripting console. (For example, bring up the console
and type in a command to rotate the molecule by 20 degrees.)
The best approach to this, IMHO, is to create a SWIG “wrapper” around
libavogadro headers. I’ve done this for Open Babel, and the result is
generally a decent Python and Ruby interface to Avogadro. Other
languages can also be supported (e.g., Java).
I think the SWIG approach is a good one as it exposes so much of the
underlying API and, as my understanding is that the wrapping is largely
automatic, that new functions become available as they are added. Providing
an additional wrapper on top of this (ala pybel) to create an easy way to
access commonly used functionality might be necessary if you want to create
something that’s not too cumbersome to use interactively.
On the subject of interactive shells - and this might be a bit of a
distraction - I got wind of a project called iPython
(http://ipython.scipy.org/moin/) that provides a powerful interactive
shell for python. I haven’t had the chance to play with it myself, but
it does seem to address some of the annoyances I’ve found with the IDLE
shell that we use to provide an interactive shell for the CCP1GUI.
I think there are a few possible steps before that happens.
- Check through the API and consider if new functions should be
exposed.
- For example, rotating, translating, and zooming the camera.
(Also useful to consolidate similar code across different tools.)
- Rotating, translating, etc. groups of atoms.
- Changing tools
- Changing rendering engines, options, etc.
- Consider if extension.h needs to be part of Avogadro
- This would let us write extensions in scripting languages.
- This would let common extensions (e.g., adding/removing hydrogens)
be part of libavogadro and shared by Kalzium, etc.
- Consider how loading file works in Avogadro (i.e., mainwindow.cpp)
- What if scripting libavogadro opens a file in the window – do we
need a signal that the molecule (or file) changed in the window?
- Should scripts be allowed to save files?
etc.
In the CCP1GUI we’ve addressed this in the rather ad-hoc fashion of
having a bunch of callbacks that go both ways between the various
objects. We need this because (for example) our coordinate editor can
change the structure that is being viewed with the main render window,
and it’s also possible for the user to edit the structure that appears
in the coordinate editor by clicking in the main window.
As another example, the calculation interfaces for codes like GAMESS-UK, Dalton
and Molpro display the basis sets that have been assigned to the atoms.
If the user changes the structure in the main window, the interface needs
to be informed of this so that it can display the correct atoms and basis sets,
so this is also implemented with callbacks.
However it’s implemented though, these sorts of changes need to be propagated between
the objects.
One way to handle #3 is to have a separate wrapper interface for
Avogadro beyond libavogadro. This would address extensions, but I
think it’s more of a hack. I feel like we should have one scripting
module.
I might be confusing issues here (and I have to confess that I don’t have
much experience with the internals of Avogadro yet), but I think it might
be useful to create some separation between the plugin, scripting and
interactive shell uses. Writers of plugins will need to have as much of
the API available to them as possible (and certainly need to be able to do
things like save files), but the scripting and interactive use probably needs
to be wrapped again to keep it easy to use.
As another aside - and I haven’t really looked at this project myself other
than to download it and play about with it a little - the ballview
project (http://www.ballview.org/) seems to be a very proficient project
and one that shares a lot of the goals of the avogadro project. They’ve
got an interactive python shell in their program, so it might be
interesting to see how they have done it.
I hope these comments are of some use. If you want me to expand on
anything just let me know.
Best wishes,
Jens
–
Jens Thomas, email: j.m.h.thomas@dl.ac.uk
STFC Daresbury Lab, tel: +44-1925-603849
Warrington, fax: +44-1925-603634
WA4 4AD, UK. http: http://www.cse.scitech.ac.uk
–
Jens Thomas, email: j.m.h.thomas@dl.ac.uk
STFC Daresbury Lab, tel: +44-1925-603849
Warrington, fax: +44-1925-603634
WA4 4AD, UK. http: http://www.cse.scitech.ac.uk
