As far as writing the code goes - I've discovered that there are some potential hurdles to implementing this "properly" due to the way Inkscape extensions currently work, which I believe is as follows:

1) The working document is written to a file

2) The extension script (typically a Python file, but perl, ruby and sh appear to be supported) is executed by calling the appropriate interpreter as a separate process, with selected element IDs and current document provided as input

3) The extension script transforms the SVG and writes it to stdout

4) The extension script reloads the file that the extension wrote to stdout, and replaces its existing document with the newly written one.

If we are to run verbs / change selections on the document, in a vaguely efficient manner, it means that the script would have to either:

a) send its results back to Inkscape before each verb execution, get Inkscape to run the verb, and then reload the new version immediately afterwards before the script can continue (slow, but fits the existing async communication model), or

b) operate on the actual Inkscape in-memory document itself, meaning that tighter script integration would be needed (e.g. using boost::python) and non-Python scripts would have to be supported differently (e.g. using a Python wrapper that execs the scripts in the existing way, so that all extensions are executed as Python scripts, or by having a different path for Python script execution in script.cpp)

I note that option b) is probably quite a lot of work, and might be some effort to maintain backward compatibility, and adds boost as a dependency (I don't believe Inkscape currently uses boost), while option a) is a bit more inefficient and requires inter-process communication (possibly using the existing file-based mechanism used for communication). The inefficient option a) seems like the one to go for initially, but doesn't provide much scope for future improvements to scripting - embedding boost::python looks like the best way to provide a proper integrated scripting experience. Hence...

c) I could take an "easy option" for proper scripting and implement the boost::python integrated scripting approach, but outside of the existing extension mechanism - this would give the benefits of fast, integrated scripting and a base for future scripting work to develop from, but leaves the existing extension mechanism as a bit of an evolutionary "dead end". Also, it would require adding Boost.Python as an Inkscape dependency. This type of scripting interface would be able to execute existing extensions as verbs, of course.

Thoughts from those who might be able to approve any future merge requests I make? My preference is for option c), but if a Boost dependency would be frowned upon for any reason, then option a) would be next on my list.

Cheers,

Eric