I fully agree with Ted on supporthing the adobe model. We should make it very easy for development of plugins for the system. What would be really cool, as we talked in relationship to the shuttleworth foundation money, is if we could get a python scripting environment that could be used across karbon14, sodi, Inkscape, and other apps. That way module development could be done in python.
But maybe scripting and modules should be separate? How does the gimp's script-fu and filters work?
I do think that both should be easy for mid-range users to develop scripts/modules for Inkscape.
Thoughts?
Jon
On Fri, 2003-12-05 at 07:48, Ted Gould wrote:
On Fri, 2003-12-05 at 02:40, Nathan Hurst wrote:
Ted Gould wrote:
The basic module architecture right now is derived from the Adobe Illustrator plug-in model. There are some optimizations and changes, but that's where most of the ideas come from. I had looked at others, but the Adobe one seemed the most mature (surprise), flexible and reasonable. I think the basic ideas of 'load, unload, prefs, execute' will work for just about anything in the future. But, there are lots of things that Adobe and others have done, that we'll need. The future is bright, and I'm wearing shades :)
One thing to remember about the Adobe model is that they don't want other people poking around in their code, whereas we are/should be quite happy with people adding anything they like. For example, Peter and I have been working on a new improved grids and guides system, currently written in python. We'd like to just plonk this into inkscape and see how it works before commiting to spending a few weeks petrifying it into C(++). There's no way we can do this currently using the modules code, because we need to do things like add new tools and catch all edit operations.
I guess that's one of the reasons that I like the Adobe model, I don't think to write a module someone should HAVE to look at the code. They should be able to do everything externally from some well defined interfaces. Then, we only have to support those interfaces to remain compatible - we can change everything else ;)
I do believe that there needs to be a way to allow for modules to 'register' for events so that they get them. I don't know that I expect something as low level as the grid to be ever implemented as a module, but certainly someone should be able to write a tool or something like that.
--Ted