ScriptingLanguages
I believe that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG W3C Link to EMCAScript - SVG. This would be a great shortcut to accessing the SVG structure for non XML geeks ;) --Xpressivo 15:55, 2 July 2006 (PDT)
Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the Boost Seamless Python integration.
Scripting allows many more developers to contribute, and allows new ideas to be prototyped essentially on the spot.
I think the core scripting interface should be relatively simple and language-neutral, like The_Gimp's PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.
Another great scripting language is called Lua: very small footprint, great flexibility, can be easily embedded into any C/C++ application without any strings attached (LGPL). Lua is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.
Another idea is to start extending with CORBA, while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for ORBit is pretty large, and something we could build on.
Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.
Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...
-- MenTaLguY
I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in ModuleFormat.
Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.
Of course, some decisions need to be made as to what to potentially support. This would apply to potential scripting languages and to potential features. Think of both the tasks to accomplish and of the languages to accomplish them in.
For an example of the tasks/concepts, we could think of a raster paint program (like The Gimp or PhotoShop). These deal with raster images. Additionally, it's nice to be able to work on images with different numbers of channels, different bit-depths and different colorspaces. The PhotoShop plugin API has supported all of this for years. Sadly, The Gimp did not at the begining. Thus problems with working in CMYK or in bit depths neede for Hollywood work both have been problematic for The Gimp and its plugins.
Blocking future functionality, I think, is the main thing that Inkscape needs to avoid. As MenTaLguY has said, it's best if plugins were first-class citizens. So what needs to be exposed?
Things off the top of my head:
-Document |-XML / parse tree |-view tree -UI Thingies / dialogs / user interaction -Utility calls / factories
-- JonCruz
More than one language to write extensions can help the development.
The SpiderMonkey is a great javascript engine, used by Mozilla web browser, and implements the JavaScript 2.0 specification.
JavaScript is a easy language and is the defined language to animate SVG. With the powerfull 2.0 version we can do good extensions to Inkscape.
The AST is a great idea to manipulate the SVG, but may we access in the same DOM used to DHTML. And it will be natural to DHTML scripters and developers.
It's written in C, is fast and low weight. I'm waiting to write new effects to Inkscape with my prefered language! :-)