Actually, we are developing a timeline animation like Flash by
using the python "extension". Obviously, we see more and more
functions which need to be exposed to the "extension". This is
why we raise the question if we need to define a official set of
interface in side the inkscape. We have binded a couple of features
already. However, we hope that we can use a stable interface so
that we don't need to sync with the inkscape itself in the future.

For example, we are using Node/NodeObserver API extensively. If
this is changed, we need to rewrite our system as well.

I can totally agree that bind function through actions is a good idea. Actually,
make the whole inkscape UI can be customized via method like the menu.xml
is good as well. This raise the question to adopt XUL or XForms. However, I
doubt that value of XUL or XForms in the inkscape.  It's a good concept, but
it might not worth the effort in pratice. No matter XUL or XForms, we need
to build a set of widgets to use them. Unless inkscape want to embedded
gecko or webkit inside it in the long run. Use propriatary XML format to change
the UI is more practical.

For the extension, I believe that there are other more important thing than XForms
or XUL. Use actions have solved most UI issues. Write Layer manager in XUL or
XForms might not be so interesting for me.

There are some area which is more insteresting
* Let extension get notified when the inkscape doing some jobs, such as
      * Load/Save file
      * Print
      * Change document property
* Intercept the procedure of modifying the object. Allow extension to disable the action.
For example, protect some objects generated by the extension from deleting.
* Change the layout of the inkscape so that we can embedded the whole inkscape
into another application.
* Expose some information to the extension. Such as, Selection, current group, current tool.

2010/12/15 Thinker K.F. Li <thinker@...2486...>
From: Jon Cruz <jon@...18...>
Subject: Re: [Inkscape-devel] Embed Python script engine
Date: Mon, 13 Dec 2010 19:49:47 -0800

>
> On Dec 13, 2010, at 3:20 PM, Yu-Chung Wang wrote:
>
>> 2010/12/13 Thinker K.F. Li <thinker@...2486...>
>> From: Yu-Chung Wang <wycc@...1761....2510...>
>> Subject: Re: [Inkscape-devel] Embed Python script engine
>> Date: Mon, 13 Dec 2010 19:55:05 +0800
>>
>> > * 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.
>
> XUL is, in my opinion, exactly the wrong approach for extensions. It really leverages the pixel-tweaking of detailed graphical UI construction, whereas we should be focusing on logical and functional constructs.

You had mentioned about XForms, and favor it.  So, why is XForms right
and XUL wrong?

Everybody likes logical (conceptual) and functional constructs.  It
makes things easy.  But, it also means limitations while you can not
define a flexible language to satisfy requests.  It is a kind of
over-designed/-engineered.

We all know that Inkscape supports types of input, output, ..., etc,
with current extension API.  I think it is also what Jon want to
support with new API. (right?)  I think the problem is about whether
Inkscape want to provide a restricted, and high-level, extension API
for only specific types of extensions or to provide a flexible, but
primitive, extension API for various types of extensions?

I think Inkscape has the potential be a reusable software/component
with a flexible, but primitive, extension API, but it is not ncessary
to be.

>
> That is a bit of why it's tricky to do good XUL for such approaches.
>
>
>> The inkscape use menu.xml which can be used to define a menu with actions. Once
>> the actions is defined, we can use it to construct a menu. However, it deos not support
>> dynamic menu change(in my understanding) now.
>
> Not yet.
>
> However, the tool code that constructs the toolbars is a good example of where our code is moving towards. The adaptive UI work will greatly expand upon that.
>
>
>
>

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel