From: Yu-Chung Wang <wycc@...2510...>

Subject: Re: [Inkscape-devel] Embed Python script engine

Date: Mon, 13 Dec 2010 19:55:05 +0800

> Are you saying to use the Node/NodeObserver as the SVG DOM or just
> invent a new one with the precise DOM API? I think that the
> Node/NodeObserver API is good enough for this purpose except
>
> * It's not GObject. We need it to maintain reference count so that the
> pointer in the extension won't become invalid and crash.

Since Inkscape uses Boehm to perform GC, reference ount can be
maintained with the help from Boehm.  A problem is about
cyclic-reference that is crossing address spaces of client language
and C language.  But, it is also an issue of various applications that
embed a script language.

> * There is no API to create new element.
>
> For the UI part, use action is a good idea. It will separate the
> extension from the base code.

It is not enough to provide a flexible environment.  We still need a
way to make it possible to insert a widget defined by an extension to
a specified position.  Firefox does it well (XUL overlay), but it is
complex to implement it.

>
> In addition, we may need some hooks to intercept file load/save as
> well so that the extension get opputunity to change the document
> before it is loaded and saved to do some sanity check of the file.
>

By the way, we (me and wycc) request a lot new functions.  It maybe
not a part of plan or target of Inkscape project, but it would make
Inkscape more reusable, flexible, and more potential.  We desire that
Inkscape project can support these functions.  I also like to be
involved for this part of the project if possible.

> 2010/12/13 Jon Cruz <jon@...18...>:
>>
>> On Dec 12, 2010, at 4:52 PM, Yu-Chung Wang wrote:
>>
>>> However, we need more than that. For example, we need to know the selection set is changed so that we
>>> can display some information according to the current selection. I can bind the signal or callback, which
>>> is available in the curretn codebase. But, it's better if there is an official interface for the UI related stuff.
>>>
>>> I can image that we need
>>> * Intercept some signals to know the UI change made by users
>>> * Register a new menu item or toolbar item
>>> * Add dock item into any part of the UI
>>> * Call inkscape functions. It is equal to change the current selection set and then send the verb.
>>>
>>> DBus is not a good idea since the Windows port is very important because our extension
>>> is to provide a tools for the art designer, who typically use Windows.
>>
>>
>> The general plan has been to expose a live SVG DOM to allow full interactivity. (BTW, I agree about DBus in the near term due to platform issues).
>>
>> http://www.w3.org/TR/SVG/svgdom.html
>>
>> Among other things, we will be able to expose things via DOM Events.
>> http://www.w3.org/TR/DOM-Level-2-Events/events.html
>>
>>
>> These are natural approaches for SVG since among other things they match what web authors are used to and are expanding more and more with. This is especially pertinent given the use of SVG in HTML5 and adoption by even MSIE.
>>
>> The document itself will be a live, mutable SVG DOM. The program interface will be exposed via the exact same DOM/Events approach. The key will be to get standard names for functions and parameters, roughly corresponding to a cleanup of our verbs and their identifiers.
>>
>> Another key concept is to focus on the *logical* approach to the UI, and not a *physical* one. Keep in mind that menu items might be moved, and toolbar items definitely will be moved by individual users dynamically at runtime. So for example that means not adding a new toolbar item or a new menu item. Instead one will add a new *action* that can be placed at various and/or multiple locations in the UI.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
>> new data types, scalar functions, improved concurrency, built-in packages,
>> OCI, SQL*Plus, data movement tools, best practices and more.
>> http://p.sf.net/sfu/oracle-sfdev2dev
>> _______________________________________________
>> Inkscape-devel mailing list
>> Inkscape-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel