Re: [Inkscape-devel] Embed Python script engine
Is the link become available in the WIKI? We are actually working on adding scene and animation editor into the inkscape. This will make the inkscape become an environment similiar to the Abobe Flash. So far, we have finished some prototype to edit multi page SVG file and some simple animation support.
So far, in the integration is only at the Node and NodeObserver level, therefore, its relationship between inkscape and python VM is quite weak.
However, in order to make it easier to use, we need to bind more and more functions into the python. This will make the binding easier to be broken from version to version. This is why we want to make it into the code base.
The other possibility is not to put the python into the code base directly. Instead, define an binding interface which should be used by any system like ours so that we can develop our stuff outside the code base safely. You can decide to include our stuff or not until the technical issue is clear.
I'll list out a few more details on this in the wiki, so that the reoccurring discussion can be captured.
2010/12/11 Yu-Chung Wang <wycc@...2510...>:
The other possibility is not to put the python into the code base directly. Instead, define an binding interface which should be used by any system like ours so that we can develop our stuff outside the code base safely. You can decide to include our stuff or not until the technical issue is clear.
There is a DBus API available in the development version. It currently works only on Linux. You may use it as a language-neutral binding.
Regards, Krzysztof.
On Dec 12, 2010, at 5:56 AM, Krzysztof Kosiński wrote:
2010/12/11 Yu-Chung Wang <wycc@...2510...>:
The other possibility is not to put the python into the code base directly. Instead, define an binding interface which should be used by any system like ours so that we can develop our stuff outside the code base safely. You can decide to include our stuff or not until the technical issue is clear.
There is a DBus API available in the development version. It currently works only on Linux. You may use it as a language-neutral binding.
Just take care that the *content* and form of the API is not ready for full extensions, and the GSoC project that added it was only focused on getting *some* DBus interface running, not in getting the final interface Inkscape will be providing in the long term.
For the content part, the current Node/SPObject API is pretty good already. We can modify the Node and use the NodeObserver to get the modification which is done inside the inkscape. Since the SPObject is an instance of GObject, the reference count is maintained. The Node is an issue since it is not GObject. Therefore, we will not save the reference to it and use the SPObject instead.
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.
2010/12/13 Jon Cruz <jon@...18...>
On Dec 12, 2010, at 5:56 AM, Krzysztof Kosi??ski wrote:
2010/12/11 Yu-Chung Wang <wycc@...2510...>:
The other possibility is not to put the python into the code base
directly.
Instead, define an binding interface which should be used by any system like ours so
that we
can develop our stuff outside the code base safely. You can decide to include our
stuff
or not until the technical issue is clear.
There is a DBus API available in the development version. It currently works only on Linux. You may use it as a language-neutral binding.
Just take care that the *content* and form of the API is not ready for full extensions, and the GSoC project that added it was only focused on getting *some* DBus interface running, not in getting the final interface Inkscape will be providing in the long term.
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
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.
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. * 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.
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.
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
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
2010/12/13 Thinker K.F. Li <thinker@...2486...>
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.
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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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@...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.
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.
On 2010-12-14 04:49, Jon Cruz wrote:
On Dec 13, 2010, at 3:20 PM, Yu-Chung Wang wrote:
2010/12/13 Thinker K.F. Li<thinker@...2486...> ... 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. ...
I agree, making Inkscape "understand" what an extension does makes it possible to a lot of things centrally, and thus consistently. It also makes it a lot easier to evolve the interface and tie things together. (Not to mention that it makes it a lot easier to develop and maintain an extension.)
Also, some mention was made of things like a time-line, and I agree that it might be hard to make Inkscape "understand" that when it has no concept of a time-line. I would like to argue though that perhaps it might be better to first make sure Inkscape DOES have such a concept and then thinking of a UI. Or, alternatively, if you want to go really overboard with UI changes, I could imagine Inkscape separating the UI from rendering and such. In that case you could conceivably build a completely different UI on top of the same core technology.
2010/12/14 Jasper van de Gronde <th.v.d.gronde@...528...>:
On 2010-12-14 04:49, Jon Cruz wrote:
On Dec 13, 2010, at 3:20 PM, Yu-Chung Wang wrote:
2010/12/13 Thinker K.F. Li<thinker@...2486...> ... 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.
> ...
I agree, making Inkscape "understand" what an extension does makes it possible to a lot of things centrally, and thus consistently. It also makes it a lot easier to evolve the interface and tie things together. (Not to mention that it makes it a lot easier to develop and maintain an extension.)
Also, some mention was made of things like a time-line, and I agree that it might be hard to make Inkscape "understand" that when it has no concept of a time-line. I would like to argue though that perhaps it might be better to first make sure Inkscape DOES have such a concept and then thinking of a UI. Or, alternatively, if you want to go really overboard with UI changes, I could imagine Inkscape separating the UI from rendering and such. In that case you could conceivably build a completely different UI on top of the same core technology.
In order to make inkscape understand what is timeline, there are two approaches.
(1) Add the timeline concept into the inkscape directly. (2) Add the time line concept in the extension. The time line is constructed by using the function available in the inkscape.
Currently, I take the second appraoch. The time line is exactly implemented as a sub layer. Any layer in the inkscape can have multiple sub layer. The timeline UI ensure that only one of them are visible. For the inkscape itself, it does not need to know the timeline at all.
The inkscape itself is too complex for average people to extend it in the C++ directly. However, a well-designed extension will allow more people to reuse the wheel invented by the inkscape for diffrerent purposes. I try to use the existing extension to implement timeline before. However, it's obvious that the current extension model is not power enough for this purpose. This is why Thinker start to implement a new script engine, whose target is to use our purpose to figure out the appropriate extension framework for the inkscape and then we can have a complete python script environment for the inkscape.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2010-12-14 11:15, Yu-Chung Wang wrote:
2010/12/14 Jasper van de Gronde<th.v.d.gronde@...528...>:
... Also, some mention was made of things like a time-line, and I agree that it might be hard to make Inkscape "understand" that when it has no concept of a time-line. I would like to argue though that perhaps it might be better to first make sure Inkscape DOES have such a concept and then thinking of a UI. Or, alternatively, if you want to go really overboard with UI changes, I could imagine Inkscape separating the UI from rendering and such. In that case you could conceivably build a completely different UI on top of the same core technology.
In order to make inkscape understand what is timeline, there are two approaches.
(1) Add the timeline concept into the inkscape directly. (2) Add the time line concept in the extension. The time line is constructed by using the function available in the inkscape.
Currently, I take the second appraoch. The time line is exactly implemented as a sub layer. Any layer in the inkscape can have multiple sub layer. The timeline UI ensure that only one of them are visible. For the inkscape itself, it does not need to know the timeline at all. ...
To give an example why having a high level abstraction layer for extensions(!) will ultimately make it easier to write and maintain extensions, consider shortcuts. A few months back I changed tooltips for "Actions" to show the associated keyboard shortcut (if any). The main problem in doing so was that unfortunately Actions aren't used (consistently) everywhere yet to expose functionality, if they had been it probably would have taken me only half the time to make this change (if not less). Imagine that extensions would have to take care of such things on their own...
Now imagine something more serious than playing with tooltips, consider changing toolkits, changing from using menus and toolbars to using ribbons (no please, but still), or even just a different kind of toolbar. Or what about changing how we handle windows like the fill&stroke and alignment dialogs. If extensions have to be aware of how we do such things and take care of it themselves then we are bound to run into a maintainability nightmare sooner or later (probably sooner), not to mention inconsistencies and such. It would also dramatically raise the bar for people to contribute extensions, as they would necessarily have to know how to program a GUI.
So instead of letting an extension put an icon/button in a certain toolbar/menu we should let extensions create actions for example. Obviously this still needs a lot of work, but in the end it should save us a lot of headaches. Note that embedding the Python interpreter is not necessarily a problem, it's just that it might be better to let the exposed API focus on providing a high level abstraction.
In the (very) long run I /could/ imagine exposing more low-level functionality, but more in an attempt to move part of Inkscape's code to Python (or some other higher level language) than to allow more advanced "extensions". I could potentially see animation support coming to Inkscape through this route, but preferrably after we have a more advanced extension system, to avoid the aforementioned problems.
BTW, in case we misunderstood each other, I thought you were talking about a timeline for supporting animation or something like that (a timeline as part of the UI). I would not exactly advocate implementing animation support as just another "extension". An extension to draw timelines shouldn't be a big problem in any extension system, and especially easy in one that provides a high-level abstraction layer (DOM, plus some extras perhaps), as you then don't need to worry about Inkscape's internals.
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@...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.
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@...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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Dec 14, 2010, at 3:48 PM, Yu-Chung Wang wrote:
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.
Yes, it needs to be stable... but most functionality that is common to SVG (such as base animation) is needed inside of Inkscape itself. The providing it in a consistent manner to *all* extensions, not just your custom Python binding, will bring the most end-user benefit.
For example, we are using Node/NodeObserver API extensively. If this is changed, we need to rewrite our system as well.
Yes, these are likely to change over time. The DOM API will not be, as that has already been defined by external standards bodies. Or rather it will not change for SVG 1.1 but will be different for SVG 2.0.
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.
XUL is very very different from XForms. The latter presents some abstract data models and allows the hosting presentation to render them however it wants.
Oh, and we already are using it for our extension .inx support. Parameters are implemented via declarative functional UI, and and provide rendering 'hints' to allow inkscape to provide the more appropriate GTK widgets as needed.
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
Yes, those are supported via the 'UI' DOM and DOM Events. And events such as the change document are already defined by XForms.
- Intercept the procedure of modifying the object. Allow extension to disable the action.
For example, protect some objects generated by the extension from deleting.
Yes, this two is completely supported via DOM Events. The order, canceling, overriding, etc. has all been worked out and refined. It does have a few shortcomings, but our current dual-tree model has even more (look to the bugs with layer renaming, etc. for examples of those problems)
http://xformsinstitute.com/essentials/browse/ch07.php#ch07-2-fm2xml
"capture" and "bubbling" are the concepts you're most likely interested in.
- Change the layout of the inkscape so that we can embedded the whole inkscape
into another application.
This actually starts to get quite tricky. Experience with XEmbed, CORBA, Bonobo, OLE, OpenDoc, etc. comes into play to help understand some of the problems.
- Expose some information to the extension. Such as, Selection, current group, current tool.
All feasible with DOM and DOM Events.
Hi, all,
I've already embedded into Inkscape: the C Python Engine, Java, Jruby, and Jython. It's not hard. All that needs agreement is the API.
What needs agreement is which internal "guts" of Inkscape need to be exposed in an API. The rest comes easily.
Bob Jamison bob.jamison@...400... (ishmal)
It's interesting. Where is your work?
We are working on C Python right now in https://launchpad.net/~inkscape-pybind.
2010/12/15 Bob Jamison <ishmalius@...400...>:
Hi, all,
I've already embedded into Inkscape: the C Python Engine, Java, Jruby, and Jython. It's not hard. All that needs agreement is the API.
What needs agreement is which internal "guts" of Inkscape need to be exposed in an API. The rest comes easily.
Bob Jamison bob.jamison@...400... (ishmal)
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
From: Bob Jamison <ishmalius@...400...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Wed, 15 Dec 2010 00:53:03 -0600
Hi, all,
I've already embedded into Inkscape: the C Python Engine, Java, Jruby, and Jython. It's not hard. All that needs agreement is the API.
What needs agreement is which internal "guts" of Inkscape need to be exposed in an API. The rest comes easily.
If you had read messages of last two days of this list, you will find that the API is what we stucked for. By the way, we can cooperate in embedding client language for Inkscape if you can share you works with us.
From: Jon Cruz <jon@...18...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Tue, 14 Dec 2010 19:35:00 -0800
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.
XUL is very very different from XForms. The latter presents some abstract data models and allows the hosting presentation to render them however it wants.
If you means data-model of XForms, I must to say that XUL also provides equivalent facility.
Oh, and we already are using it for our extension .inx support. Parameters are implemented via declarative functional UI, and and provide rendering 'hints' to allow inkscape to provide the more appropriate GTK widgets as needed.
The typical example of Firefox to use data-model is for UI of preference. I think it is what you said difference.
The data-model of XUL can comes from RSS/XML/or database. Since Inkscape have used XForms, just forget XUL. I just clear the misunderstanding for XUL.
From: Jon Cruz <jon@...18...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Tue, 14 Dec 2010 19:35:00 -0800
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
Yes, those are supported via the 'UI' DOM and DOM Events. And events such as the change document are already defined by XForms.
- Intercept the procedure of modifying the object. Allow extension to disable the action.
For example, protect some objects generated by the extension from deleting.
Yes, this two is completely supported via DOM Events. The order, canceling, overriding, etc. has all been worked out and refined. It does have a few shortcomings, but our current dual-tree model has even more (look to the bugs with layer renaming, etc. for examples of those problems)
http://xformsinstitute.com/essentials/browse/ch07.php#ch07-2-fm2xml
"capture" and "bubbling" are the concepts you're most likely interested in.
Do you means XForms can do or Inkscape had worked like it?
In order to make sure we are taliking to the same thing. Let me summary the discussion so that we can go on from here.
(1) The current Node/SPObject will be replaced or encapsulated by the SVG DOM data modeling so that all extension will rely on the SVG DOM data and events only. (2) Some UI DOM might be defined to expose inkscape to the extension. For example, the current group or color or fill will be exposed as an node in the "UI" DOM. (3) A DOM-like API will be provided by the inkscape core so that the extension should wrap this API in their own langauge. (4) extension should define the UI as an action. The whole inkscape UI will be constructed in the XForm as well.
Let me try to simulate it in my purpose. (1) We need to insert some menu item and submenu into the main menu. (2) In order to monitor the change in the layer manager, we only need to add listener to the event DOMSubtreeModified for all elements whose "groupmode" is "layer". We may need to listen to DOMNodeInserted as well to check if there is any new layer is added. The DOMNodeRemoved need to be listened as well. (3) In order to intercept the load/save/print, we will register to the SVGLoad/SVGUnload. We need some extension, such as SVGSave or SVGPrint for save/print. (4) For the current selection/color/fill/font, we need to define a special DOM object "inkscape" with the follwing structure. inkscape:uiinkscape:selection<item xlink="g3344" /><item xlink="g1122" /></inkscape:selection></inkscape:ui>
In my point of view, XForm is less important compared to the SVG DOM. The extension should use their native widgets(for us. it's pygtk) to write the UI and then add it into inkscape by some kind of docking mechanism is easy and clean. Implement Xform in both inkscape and extension is good in concept. However, in practical, I doubt it worth the effort. Think about this. We need to support the Xform Core module in both inkscpae and extension. The only thing we get is to enable the interaction between two UI natively. However, similar function can be implemented much easy by using the DOM as the common data store.
Multiple UI can work on the same synchronized SVG DOM. Once the DOM is changed by any side, the other side is notified by the DOM events and do some reaction.
YC
2010/12/15 Thinker K.F. Li <thinker@...2486...>
From: Jon Cruz <jon@...18...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Tue, 14 Dec 2010 19:35:00 -0800
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
Yes, those are supported via the 'UI' DOM and DOM Events. And events such
as the change document are already defined by XForms.
- Intercept the procedure of modifying the object. Allow extension to
disable the action.
For example, protect some objects generated by the extension from
deleting.
Yes, this two is completely supported via DOM Events. The order,
canceling, overriding, etc. has all been worked out and refined. It does have a few shortcomings, but our current dual-tree model has even more (look to the bugs with layer renaming, etc. for examples of those problems)
http://xformsinstitute.com/essentials/browse/ch07.php#ch07-2-fm2xml
"capture" and "bubbling" are the concepts you're most likely interested
in.
Do you means XForms can do or Inkscape had worked like it?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
From: Jon Cruz <jon@...18...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Sun, 12 Dec 2010 21:51:55 -0800
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.
I think it is good, but not necessary, for a tool likes Inkscape to expose SVG DOM compatible tree. My question is when to do it. Is there any plan or schedule?
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.
High-level logical one is also good. But, it is not practical for an environment with various requests when you can not provide a mechanism that is flexible enough. For example, it is hard to implement a timeline-like widget with a logical *action* except defining a logical *action type* for timeline. (if a logical action what is defined by extension, now) To provide *logic action* is good, but we should still keep the capabilities of making GUI controllers with toolkit/GTK's way.
participants (6)
-
Bob Jamison -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński -
Thinker K.F. Li -
Yu-Chung Wang