Trent Buck wrote:
Since C / C++ lack an interpreted component. Therefore you have to use a scripting language (e.g. python, scheme), which in turn requires writing C -> scripting language glue. To do it `properly' (i.e. the user as access to every layer of Inkscape internals as first-class procedures in the scripting language), you'd have to write a *lot* of glue (say, five lines of code per Inkscape function).
Ahhh... and this is where we've looked into some things. One minor point is that often even if something is in some interpreted component it still might be difficult to add good scripting if there's not a good interface/API on everything.
However, to do it properly we're looking at SWIG. It's made for exposing C++ to various scripting languages including Tcl, Python, Perl, Guile, Java, Ruby, Chicken and more. The good news is that it takes care of all that glue for you. Just list the functions to be exposed, run and voila!
And we also have Bob bringing in most of the related DOM interfaces. That in turn gives us a nice, clean, well thought out interface to document guts.
This is compared to writing extensions for an application that is mostly written in the same language (e.g. emacs), where the user-written code is no different from the pre-written code.
Sometimes. But then sometimes other. Part of what emacs so extensible is well defined paradigms and interfaces. :-)
Note that I'm not saying Inkscape should have been written in another language. I'm merely pointing out that to now *add* user-programmability will take a lot of work. I could, also, be dead wrong. I've never done it before, so this is all speculation.
Thankfully in this case you're only a bit off. :-)
In the roadmap we've had scripting and extensions for a while now, and as the other code's been done scripting has been at least kept in mind. Also much of the intent has been for extensions to be 'first class citizens' in the Inkscape runtime. This helps add to potential user scripting. And many of the core developers are into strange languages like Python and Ruby, so we're trying to keep options open.
Could the extension/plugin/scripting support be leveraged to sole problems like this one?
Yes, programmability would allow you to script such actions, easily. The difficulty is not the problem->solution->script arc, but the script->compiled-code arc (or so I believe).
Yes, this is where the main effort lies. However, there are things like SWIG and having nice interfaces designed that can help this happen quicker. And there's that the extensions mechanism is intented to allow for nice user scripting.
Additionally, there's some experimental Glade and C++ working going on that could help a lot with extensions running UIs, and might even end up with some suprisingly nice results. Anyway, there's lots of stuff going on in this area right now.