On Sat, 2004-01-03 at 16:19, Bryce Harrington wrote:
We had briefly toyed with the idea of dividing out the Inkscape::Extension namespace according to different types of extensions, but decided to leave that 'til later since it was beyond the scope of what we were doing. We were also uncertain if sub-namespaces were even necessary. You might want to give some thought to it, though. We identified a few things that could be covered by this namespace: import/export mechanisms, GUI plugins, stdin/stdout programs, language bindings, etc.
Here's what I'm working on converting to:
Inkscape::Extension::extension (virtual class) Inkscape::Extension::input (inherit from extension) Inkscape::Extension::output (inherit from extension) Inkscape::Extension::filter (inherit from extension) Inkscape::Extension::print (inherit from extension)
Inkscape::Extension::Implementation::implementation Inkscape::Extension::Implementation::script (inherit from implementation)
Then, internal modules just need to create a class inheriting from implementation for what they want to do, and then all the other functions will work happily. So then the SVG stuff will create the class
Inkscape::Extension::Implementation::svg (inherit from implementation)
And the gnome-print stuff will create
Inkscape::Extension::Implementation::gnomeprint (inherit from implementation)
And each of these will implement the functions that they are interested in for their functionality. Those will get overloaded, and the others will work as stubs. I thought about breaking out the implementation stuff into input/output/filter/print also, but I thought the the overloading worked as well, and was less work to code. Plus it makes it easier to add additional types of modules (like file selector).
--Ted