Difference between revisions of "Extension architecture proposals"

From Inkscape Wiki
Jump to navigation Jump to search
Line 1: Line 1:
Please place your extension architecture proposals here. Everyone will review them and we will decided a course of action after we release 0.38.
Please place your extension architecture proposals here. Everyone will review them and we will decided a course of action after we release 0.38.


<b>Tasks</b>
=== Tasks ===


Design Phase:
Design Phase:
 
* Flesh out each category of functions in the API with ideas for what the functions should be
    * Flesh out each category of functions in the API with ideas for what the functions should be
* Solidify the underlying Extension infrastructure [Ted]
    * Solidify the underlying Extension infrastructure [Ted]
* Create an example Extension package
    * Create an example Extension package
* Write a specification document, including:
    * Write a specification document, including:
** Overview of Inkscape Extensions
          o Overview of Inkscape Extensions
** Creating an Extension
          o Creating an Extension
** Registering an Extension
          o Registering an Extension
** Custom Extension Preferences
          o Custom Extension Preferences
** Extension API Definition
          o Extension API Definition  


Implementation Phase:
Implementation Phase:
* Implement Extension API
* Implement an Extension registry
* Create Extension preferences dialog
* Create web tool for contributing new Extensions


    * Implement Extension API
=== Terminology ===
    * Implement an Extension registry
    * Create Extension preferences dialog
    * Create web tool for contributing new Extensions


<b>Terminology</b>
* Extension - An extension is something that extends the functionality of Inkscape without being directly part of the core.  This implies that it should be easy to remove or add, and nothing in the core should depend on it directly.
* Plug-in - An extension that is implemented through a loadable library.  This is a .o file on Unix-like systems or a .dll on Win32.  The libraries should not be loaded until they are used.
** PlugIns discussion
* Script - A script is a type of extension that is implemented through an external program that recieves and sets SVG data through files and pipes.  This allows Inkscape to use programs that handle SVG but are targeted differently seemlessly inside of Inkscape.
** ScriptingLanguages discussion
* Module - As far as I am aware the only definition of this word in Inkscape is that it was previously used to describe an extension.  The word is deprecated ;)


    * Extension - An extension is something that extends the functionality of Inkscape without being directly part of the core. This implies that it should be easy to remove or add, and nothing in the core should depend on it directly.
=== Inkscape Extension API ===
    * Plug-in - An extension that is implemented through a loadable library. This is a .o file on Unix-like systems or a .dll on Win32. The libraries should not be loaded until they are used.
          o PlugIns discussion
    * Script - A script is a type of extension that is implemented through an external program that recieves and sets SVG data through files and pipes. This allows Inkscape to use programs that handle SVG but are targeted differently seemlessly inside of Inkscape.
          o ScriptingLanguages discussion
    * Module - As far as I am aware the only definition of this word in Inkscape is that it was previously used to describe an extension. The word is deprecated ;)
 
<b>Inkscape Extension API</b>


Describe things that one may want to use the API for:
Describe things that one may want to use the API for:


    * Ability to load/print/save/close documents  
* Ability to load/print/save/close documents
 
     SPDocument * sp_file_open (gchar * uri, Inkscape::Extension::Input * ext)
     SPDocument * sp_file_open (gchar * uri, Inkscape::Extension::Input * ext)
     bool sp_file_save (SPDocument * doc, gchar * uri, Inkscape::Extension::Output * ext)
     bool sp_file_save (SPDocument * doc, gchar * uri, Inkscape::Extension::Output * ext)
     bool sp_print_doc (SPDOcument * doc)
     bool sp_print_doc (SPDOcument * doc)
 
* Access to the document's SVG::DOM object hierarchy
    * Access to the document's SVG::DOM object hierarchy  
 
     array  getElements(string element_name)
     array  getElements(string element_name)
     string getElementName?()
     string getElementName()
     string getElementByID?(string id)
     string getElementByID(string id)
     string getElementID?()
     string getElementID()
     hash  getAttributes()
     hash  getAttributes()
     string getAttribute(string attribute)
     string getAttribute(string attribute)
     bool  SetAttribute?(string name, string value)
     bool  SetAttribute(string name, string value)
     bool  SetAttributes?(hash)
     bool  SetAttributes(hash)
     bool  hasChildren()
     bool  hasChildren()
     array  getChildren()
     array  getChildren()
     obj    getFirstChild?()
     obj    getFirstChild()
     obj    getLastChild?()
     obj    getLastChild()
     array  getSiblings()
     array  getSiblings()
     obj    getNextSibling?()
     obj    getNextSibling()
     obj    getPrevSibling?()
     obj    getPrevSibling()
     int    getChildIndex?()
     int    getChildIndex()
     obj    getChildAtIndex?(int index)
     obj    getChildAtIndex(int index)
     obj    getParent()
     obj    getParent()
     array  getParents()
     array  getParents()
Line 65: Line 60:
     bool  isDescendant(obj)
     bool  isDescendant(obj)
     cdata  getCDATA()
     cdata  getCDATA()
* Access to all Inkscape verbs
* Access to preferences
* Access to global def's
** Gradients
** Markers
** Patterns
* Access to share resources (clipart, templates, etc.)
* Extension based variables


    * Access to all Inkscape verbs
These are the variables that control settings for the individual extension. Things that are held internally, but should be saved with the Inkscape preferences. These are:
    * Access to preferences
    * Access to global def's
          o Gradients
          o Markers
          o Patterns
    * Access to share resources (clipart, templates, etc.)
    * Extension based variables
 
These are the variables that control settings for the individual extension. Things that are held internally, but should be saved with the Inkscape preferences. These are:


     get_param (gchar * name, [bool, int, gchar *] data)
     get_param (gchar * name, [bool, int, gchar *] data)


    This function gets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string.  
: This function gets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string.


     set_param (gchar * name, [bool, int, gchar *] data)
     set_param (gchar * name, [bool, int, gchar *] data)


    This function sets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string. In the case of the string it is copied.  
: This function sets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string. In the case of the string it is copied.


For examples of API functions, see the perl SVG, SVG::DOM, et al modules
For examples of API functions, see the perl SVG, SVG::DOM, et al modules


<b>Inkscape Extension Archive Network</b>
=== Inkscape Extension Archive Network ===


Initially, distributing extensions with Inkscape itself will be okay but ultimately for them to truly be extensions they should exist external to the core Inkscape project, which means we need some way to receive and manage contributions. Perl's CPAN provides an excellent model for how this type of module-contribution system can be made to work. Some important characteristics of CPAN worth adopting here:
Initially, distributing extensions with Inkscape itself will be okay but ultimately for them to truly be extensions they should exist external to the core Inkscape project, which means we need some way to receive and manage contributions. Perl's CPAN provides an excellent model for how this type of module-contribution system can be made to work. Some important characteristics of CPAN worth adopting here:


   * Indexes of best items are available (e.g. 'best of')
   * Indexes of best items are available (e.g. 'best of')

Revision as of 13:02, 7 July 2004

Please place your extension architecture proposals here. Everyone will review them and we will decided a course of action after we release 0.38.

Tasks

Design Phase:

  • Flesh out each category of functions in the API with ideas for what the functions should be
  • Solidify the underlying Extension infrastructure [Ted]
  • Create an example Extension package
  • Write a specification document, including:
    • Overview of Inkscape Extensions
    • Creating an Extension
    • Registering an Extension
    • Custom Extension Preferences
    • Extension API Definition

Implementation Phase:

  • Implement Extension API
  • Implement an Extension registry
  • Create Extension preferences dialog
  • Create web tool for contributing new Extensions

Terminology

  • Extension - An extension is something that extends the functionality of Inkscape without being directly part of the core. This implies that it should be easy to remove or add, and nothing in the core should depend on it directly.
  • Plug-in - An extension that is implemented through a loadable library. This is a .o file on Unix-like systems or a .dll on Win32. The libraries should not be loaded until they are used.
    • PlugIns discussion
  • Script - A script is a type of extension that is implemented through an external program that recieves and sets SVG data through files and pipes. This allows Inkscape to use programs that handle SVG but are targeted differently seemlessly inside of Inkscape.
    • ScriptingLanguages discussion
  • Module - As far as I am aware the only definition of this word in Inkscape is that it was previously used to describe an extension. The word is deprecated ;)

Inkscape Extension API

Describe things that one may want to use the API for:

  • Ability to load/print/save/close documents
    SPDocument * sp_file_open (gchar * uri, Inkscape::Extension::Input * ext)
    bool sp_file_save (SPDocument * doc, gchar * uri, Inkscape::Extension::Output * ext)
    bool sp_print_doc (SPDOcument * doc)
  • Access to the document's SVG::DOM object hierarchy
    array  getElements(string element_name)
    string getElementName()
    string getElementByID(string id)
    string getElementID()
    hash   getAttributes()
    string getAttribute(string attribute)
    bool   SetAttribute(string name, string value)
    bool   SetAttributes(hash)
    bool   hasChildren()
    array  getChildren()
    obj    getFirstChild()
    obj    getLastChild()
    array  getSiblings()
    obj    getNextSibling()
    obj    getPrevSibling()
    int    getChildIndex()
    obj    getChildAtIndex(int index)
    obj    getParent()
    array  getParents()
    bool   isAncestor(obj)
    bool   isDescendant(obj)
    cdata  getCDATA()
  • Access to all Inkscape verbs
  • Access to preferences
  • Access to global def's
    • Gradients
    • Markers
    • Patterns
  • Access to share resources (clipart, templates, etc.)
  • Extension based variables

These are the variables that control settings for the individual extension. Things that are held internally, but should be saved with the Inkscape preferences. These are:

    get_param (gchar * name, [bool, int, gchar *] data)
This function gets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string.
    set_param (gchar * name, [bool, int, gchar *] data)
This function sets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string. In the case of the string it is copied.

For examples of API functions, see the perl SVG, SVG::DOM, et al modules

Inkscape Extension Archive Network

Initially, distributing extensions with Inkscape itself will be okay but ultimately for them to truly be extensions they should exist external to the core Inkscape project, which means we need some way to receive and manage contributions. Perl's CPAN provides an excellent model for how this type of module-contribution system can be made to work. Some important characteristics of CPAN worth adopting here:

  * Indexes of best items are available (e.g. 'best of')
  * Redundant modules are tolerated
  * Automate testing of included test suites on various platforms
  * Naming requirements to be included in indexes
  * Removal of malicious items
  * Manual application for user id on the system
  * Documentation for each module is online and nicely formatted
  * Integrated bug tracking system
  * Need to divide 'development' and 'stable'
  * Need to identify poor style, over-complexity.
  * Feedback to author should be personal so avoids public ranting
  * Use of review forms instead of freeform feedback?
  * Use of per-module discussion forums?
  * Establish forum for thanks and positive feedback
  * Like freshmeat/sourceforge, report on # downloads, vitality, etc.