Scripting Support

Since several people will be at the “tools summit” next week, I
thought I’d outline some thoughts about scripting support for
Avogadro. There are several options.

http://avogadro.openmolecules.net/wiki/Scripting

I think one of the fastest ways to get embedded scripts into Avogadro
will be with PythonQt or Kross. These allow scripts via Qt meta-
objects (i.e., moc). Anything which is a QObject-derived class is fair
game. Both of these can be used with PyQt or other toolkits to make
menus, dialogs, etc.

I think eventually, we’ll want to have SWIG or SIP bindings to
libavogadro, which will also make it possible for libavo to be
embedded in purely Python applications (rather than Python scripts in
Avogadro). But that’s going to take more work.

Does this sound like a good approach? Python is the most widely
requested scripting language. Are there others which are critical?

Cheers,
-Geoff

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 there are a few possible steps before that happens.

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

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.

Thoughts?
-Geoff

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.

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

Geoffrey Hutchison wrote:

Since several people will be at the “tools summit” next week, I
thought I’d outline some thoughts about scripting support for
Avogadro. There are several options.

http://avogadro.openmolecules.net/wiki/Scripting

I think one of the fastest ways to get embedded scripts into Avogadro
will be with PythonQt or Kross. These allow scripts via Qt meta-
objects (i.e., moc). Anything which is a QObject-derived class is fair
game. Both of these can be used with PyQt or other toolkits to make
menus, dialogs, etc.

From my reading it seems that PythonQt is probably the easiest,
although it restricts things to Python. Kross enables support for
Python, Ruby and JavaScript, and possibly more in the future. However,
as Kross is part of KDE, does this imply a bunch of other dependencies
and added complications to the build?

I think eventually, we’ll want to have SWIG or SIP bindings to
libavogadro, which will also make it possible for libavo to be
embedded in purely Python applications (rather than Python scripts in
Avogadro). But that’s going to take more work.

Is there any advantage to using SIP over SWIG? Speaking with the
authority of almost complete ignorance, it seems that you have to do
similar levels of work (create interface files) with both systems and
end up achieving similar functionality, but SWIG enables multiple
languages, whereas SIP is restricted to Python.

Does this sound like a good approach? Python is the most widely
requested scripting language. Are there others which are critical?

I can see 3 ways that scripting would be useful in Avogadro.

  1. An interactive shell that allows users to access bits of Avogadro’s
    functionality from the command-line and execute scripts (their own or
    supplied) to easily perform repetitive/complex tasks within Avogadro.

  2. A scripting interface that allows Avogadro’s functionality to be
    accessed from a shell so that certain tasks (e.g. submitting multiple
    jobs, generating a movie of a trajectory) can be performed without
    firing up the interface.

  3. The ability to extend Avogadro (e.g. write new interfaces) in (e.g.)
    Python without the complexity of having to use C++ and the compile/link
    cycle.

Would all of the above be possible using SWIG? If so it seems the best
way to go as you then expose all of the above to Perl/Ruby/Java
programmers as well as those that use Python.

Presumably PythonQt would enable some of the above to be carried out and
could maybe be used to quickly demonstrate what’s possible and get some
experience while the relevant interface files are written.

I hope those are helpful comments!

Best wishes,

Jens


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

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

http://avogadro.openmolecules.net/wiki/Scripting
From my reading it seems that PythonQt is probably the easiest,
although it restricts things to Python.

Agreed.

However, as Kross is part of KDE, does this imply a bunch of other
dependencies
and added complications to the build?

As far as I can tell, no. I contacted the Kross developers in November
and asked if Kross would become only dependent on Qt4. They said yes,
but they couldn’t do it for KDE4. Looking at the current Kross SVN
looks good.

(Keep in mind that libavogadro is part of KDE, as is Eigen.
Fortunately, not all KDE libraries depend on other kdelibs. :slight_smile:

Is there any advantage to using SIP over SWIG?

In my experience, SWIG is pretty easy. We have one interface file for
Open Babel and it includes a variety of C++ headers. SWIG reads the
headers directly and generates the code. SIP is “a small SWIG,” and
won’t read headers. You have to create a set of files which look like
headers.

My normal inclination would be to go with SWIG. It works well for Open
Babel, and as you said, it enables multiple languages. But SIP is
clearly the tool used for PyQt. So I don’t know if it has advantages
for dealing with Qt-specific issues (e.g., signals and slots) or if
we’ll run into problems using SWIG bindings to access PyQt.

  1. An interactive shell that allows users to access bits of
    Avogadro’s
    functionality from the command-line and execute scripts (their own or
    supplied) to easily perform repetitive/complex tasks within Avogadro.

This has another dependency to create a console. On the other hand,
there are several such packages, and they tend to be small – so it’s
possible for Avogadro (the app) to import code for the console. (I
hate tying us down to another dependency.)

I think this is the easiest to implement – an extension that brings
up an interactive shell. If people have suggestions for a Python-based
Qt console, please let me know.

I’d be happy to try out a set of SWIG interfaces for libavogadro. It
shouldn’t be too much work.

Cheers,
-Geoff