Difference between revisions of "QuickDrawingAPI"

From Inkscape Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by one other user not shown)
Line 2: Line 2:


===Summary===
===Summary===
:'''Update'''
:A Google summer of code project is underway to address this issue. see: http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html for details.  This interface was designed with non-technical users in mind and is currently under discussion on the Inkscape devel list.  Feel free to chime in with suggestions.


:'''Problem'''
:'''Problem'''
Line 13: Line 16:


:'''target users'''
:'''target users'''
:Me. More specific: Inkscape users (designers) with a basic understanding of scripting, for example from JavaScript/HTML/ActionScript, but without the need or desire to digg deep into code development.  
:Inkscape users (designers) with a basic understanding of scripting (for example from JavaScript/HTML/ActionScript/Visual Basic Macro's), but without the need or desire to digg deep into code development.


===Examples===
===Examples===
Line 33: Line 36:
# A series of classes that translate the requested functionality for other Python-classes that do the XML-handling.
# A series of classes that translate the requested functionality for other Python-classes that do the XML-handling.


===classes===
===Proposal for classes===
Here is a quick, incomplete draft for the classes that would be needed
Here is a quick, incomplete draft for the classes that would be needed. I'm not too familiar with the terminology of OOP, so if somebodies feels like making corrections: please!
 
*Point
**A location on the canvas.
**Properties
***x: Real, indication x-position
***y:Real, indication x-position
 
*Node
**A node as part of a path.
**Properties
***node: Point
***firstHandle: Point
***secondHandle: Point
***type: String, either:
****sharp
****smooth
****symmetric
***The handles get automatically re-calculated when the type of the node changes.''
*** Should the coordinates of the handles be relative to the node or absolute?
*** Would it be handy to define the handles as polar coordinates, relative to the direction of the path and the node?


====point====
*DrawingObject
A 2d location on the canvas.
**generic drawing object on the canvas
'''Properties''':
**properties
:x: Real, indication x-position
***fill: Fill
:y:Real, indication x-position
***outline: Outline


====node====
*Path
A node as part of a path.
**extends DrawingObject
'''Properties''':
**properties
:node: point
***nodes: Array of Node-objects
:firstHandle: point
***closed: Boolean indicating whether or not the path is closed
:secondHandle: point
**methods:'''
:type: String, either:
***addNode
:sharp
***removeNode
:smooth
***insertNode
:symmetric


I would propose that the handles get automatically re-generated when the type of the node changes.
*Circle
**extends DrawingObject
**Properties
***centerPoint: Point
***startAngle: Real
***stopAngle: Real
***open: Boolean, indicates whether or not the cirlce is drawn open between stop and start angle
***pie: Boolean, indicates whether or not lines are drawn towards the center


====path====
*Polygon, 3DCube, StraighLine, etc
'''properties'''
**extend DrawingObject
:nodes: Array of node
:closed: Boolean indicating whether or not the path is closed
:fill: Fill object
:outline: Outline object
'''methods:'''
:addNode
:removeNode
:insertNode


====selection====
*Selection
**Object that holds an array of the DrawingObjects that are selected.
**Properties
***Content: Array of DrawingObjects

Latest revision as of 16:44, 9 July 2009

This page is meant as a proposal and a discussion platform for outlining a "quick drawing API" in Python. The purpose of this page is to summarize the needs of end-users ("designers") for a collection of Python-functions to assist in the quick drawing and manipulation of graphical objects on the canvas.

Summary

Update
A Google summer of code project is underway to address this issue. see: http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html for details. This interface was designed with non-technical users in mind and is currently under discussion on the Inkscape devel list. Feel free to chime in with suggestions.
Problem
Creating an effect or "macro" in Inkscape is possible using Python, but the present tools available in Python all require XML-handling. This is contra-intuitive for a drawing program and imposes a barrier to users for creating new tools.
Solution
Create a series of pre-defined functions and classes that allow for direct creation and manipulation of drawing objects.
Benefits
Easier creation of "macros" in Inkscape will encourage designers to write and share the tools they need, thereby enhancing Inkscape functionality quickly and increasing the contribution of the community of users. This has for example happened with Blender, where the community has created a vast set of tools(among which quite many wizards) for creating and modifying the 3d models.
target users
Inkscape users (designers) with a basic understanding of scripting (for example from JavaScript/HTML/ActionScript/Visual Basic Macro's), but without the need or desire to digg deep into code development.

Examples

Before setting up the "API", I'd like to give an example of what I envision using pseudo-code. Excuse me if it looks too POSIX-style and too little Python.

myNewShape=new Path();
myNewShape.addNode([0,0]);
myNewShape.addNode([1,0]);
myNewShape.addNode([0,1]);
myNewShape.closed=true;
myNewShape.fill.fillColor=#FF0000FF;


Technical notes

I have no clue about how this all should be implemented. I see basically two options, please correct me if I use the wrong wording:

  1. An API connected to the core-functionality of Inkscape
  2. A series of classes that translate the requested functionality for other Python-classes that do the XML-handling.

Proposal for classes

Here is a quick, incomplete draft for the classes that would be needed. I'm not too familiar with the terminology of OOP, so if somebodies feels like making corrections: please!

  • Point
    • A location on the canvas.
    • Properties
      • x: Real, indication x-position
      • y:Real, indication x-position
  • Node
    • A node as part of a path.
    • Properties
      • node: Point
      • firstHandle: Point
      • secondHandle: Point
      • type: String, either:
        • sharp
        • smooth
        • symmetric
      • The handles get automatically re-calculated when the type of the node changes.
      • Should the coordinates of the handles be relative to the node or absolute?
      • Would it be handy to define the handles as polar coordinates, relative to the direction of the path and the node?
  • DrawingObject
    • generic drawing object on the canvas
    • properties
      • fill: Fill
      • outline: Outline
  • Path
    • extends DrawingObject
    • properties
      • nodes: Array of Node-objects
      • closed: Boolean indicating whether or not the path is closed
    • methods:
      • addNode
      • removeNode
      • insertNode
  • Circle
    • extends DrawingObject
    • Properties
      • centerPoint: Point
      • startAngle: Real
      • stopAngle: Real
      • open: Boolean, indicates whether or not the cirlce is drawn open between stop and start angle
      • pie: Boolean, indicates whether or not lines are drawn towards the center
  • Polygon, 3DCube, StraighLine, etc
    • extend DrawingObject
  • Selection
    • Object that holds an array of the DrawingObjects that are selected.
    • Properties
      • Content: Array of DrawingObjects