Difference between revisions of "Extension subsystem"

From Inkscape Wiki
Jump to navigation Jump to search
m (→‎See Also: update link to current trunk repo)
Line 30: Line 30:


== See Also ==
== See Also ==
* [[ScriptingHOWTO]]: an explaination of the details for creating an extension with the Script implementation.
* [[ScriptingHOWTO]]: an explanation of the details for creating an extension with the Script implementation.
* [[MakingAnINX]]: every Extension needs an INX file.  
* [[MakingAnINX]]: every Extension needs an INX file.  
* [http://sourceforge.net/mailarchive/message.php?msg_id=15742559|A message from Ted Gould] describing the functionality and implementation types.
* [http://article.gmane.org/gmane.comp.graphics.inkscape.devel/16210 A message from Ted Gould] describing the functionality and implementation types.
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/doc/extension_system.txt  The original extension architecture document from inkscape svn.] It would be good to look through this document and move pertinent facts onto this page.
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/doc/extension_system.txt  The original extension architecture document from inkscape svn.] It would be good to look through this document and move pertinent facts onto this page.

Revision as of 02:12, 15 December 2014

General

The Extension system is a way to add functionality to Inkscape. The design of the extension system is similar to the bridge design pattern, breaking apart the functionality that is being provided, and the implementation of that functionality. The term extension is used to describe all of this, the functionality and the implementation.

Functionality Provided

There are several types of functionality provided by the extensions system today, and more are slated for the future.

  • Input. Input extensions take data from a file and bring it into Inkscape. Even reading SVG files (Inkscape's native format) is implemented as an internal extension. Input extensions can be chained so that extensions can be created that don't make it all the way to SVG directly. (code reference)
  • Output. Output extensions take the data from Inkscape and turn it into a file. SVG Output is an internal extension. Output extensions can also be chained. (code reference)
  • Effect. Effects are extension that take a document, and possibly a selection, and change it in some way. This could be anything from changing colors to generating fractals. These are similar to Filters in The GIMP. (code reference)
  • Print. Print are extensions that require a little more work from Inkscape itself. They provide a set of functions that allow Inkscape to 'render' the document onto the extension. These are the most complex to implement, but can provide the most functionality to a potential developer of extensions. (code reference)
  • Path Effects. Path effects provide a way to change a path. They allow a user to edit a path using the standard Inkscape path editing tools, but then have it look differently than just a line. This could include everything from adding hash marks to making the line look like it's on fire. (not in Doxygen yet)
  • Tools. Tools are the ways that you draw in Inkscape. Rectangle tool, circle tool, star tool... the goal is to eventually have the ability to add tools as extensions. (no code)

Implementation Types

While the functionality that the extension provides is described above, how that gets done is a different story. The Inkscape extensions system allows for programmers to implement their extension in a variety of ways, trying to match their particular skillset.

  • Internal. Any extension type can be implement in C or C++ and directly linked into the Inkscape codebase. While in general the goal is to move as much out of the main Inkscape binary, this makes sense for many extensions including things like SVG input/output.
  • Scripts. Scripts are where Inkscape uses standard in and standard out on an external executable to implement the functionality. This allow Inkscape to reuse a variety of utilities that already do format conversion or implement cool things in SVG. Typically the scripts that are effects use a SVG DOM library in their programming language of choice.
  • XSLT. This implementation is done in the XSLT language, and uses libxml's XSLT parser that is already linked with Inkscape.
  • DOM Scripts. As Inkscape finishes its DOM implementation the goal will be to provide this directly to scripts. This will allow for faster execution, but also other access to Inkscape's internals and algorithms.

Maturity

The extension system is currently able to provide functionality from the Input, Output, and Effects categories. A plan has been scoped for the implementation of Path Effects but work has not yet begun. I am not aware of the status of the Tools functionality described above.

Internal and Script implementations are available to the developer. Bob Jamison (aka ishmal) has done a large amount of work toward DOM Scripts but there are not yet any working examples. I am not aware of the status of the XSLT implementation. Note: XSLT at this time appears to support input and output filtering, but not effects filters (i.e. there is no implementation of Inkscape::Extension::Implementation::XSLT::effect(), only ::open() and ::save() )

See Also