I was bugging the lib2geom folks a few months back when I had to get pulled away on another project of mine. That project has finished and I thought I'd see about helping just a little bit with Inkscape development.
I have posted a message on the lib2geom Jabber conference room.
I also thought I would find out if Inkscape had a plug-in or extension system just yet. If it did I thought I might take a stab at making small improvements to the program. I'm not an experienced C++ developer and I'm a little scared about trying to build Inkscape.
Is there an extension or plug-in system in place? Or will I need to build Inkscape to test any changes I might make?
I took a look at the road map and found these items interesting:
Revisit coordinate system (move away from Cartesian) Tech Drawing Abilities DXF Import/Export
Thanks for the help. I hope I can make time to tinker with Inkscape or lib2geom and improve my C++ skills as I work.
Landon
I got in touch with the lib2geom people. I'm going to try to do a little work on a spatial index for them. Perhaps we can eventually use that in Inkscape to speed up rendering. The lib2geom people thought it might have some other applications as well.
I'd still like to learn about the status of Inkscape's plug-in/extension system.
Thanks,
Landon
On 4/12/07, Redefined Horizons <redefined.horizons@...400...> wrote:
I was bugging the lib2geom folks a few months back when I had to get pulled away on another project of mine. That project has finished and I thought I'd see about helping just a little bit with Inkscape development.
I have posted a message on the lib2geom Jabber conference room.
I also thought I would find out if Inkscape had a plug-in or extension system just yet. If it did I thought I might take a stab at making small improvements to the program. I'm not an experienced C++ developer and I'm a little scared about trying to build Inkscape.
Is there an extension or plug-in system in place? Or will I need to build Inkscape to test any changes I might make?
I took a look at the road map and found these items interesting:
Revisit coordinate system (move away from Cartesian) Tech Drawing Abilities DXF Import/Export
Thanks for the help. I hope I can make time to tinker with Inkscape or lib2geom and improve my C++ skills as I work.
Landon
On Thu, 2007-04-12 at 16:02 -0700, Redefined Horizons wrote:
I also thought I would find out if Inkscape had a plug-in or extension system just yet. If it did I thought I might take a stab at making small improvements to the program. I'm not an experienced C++ developer and I'm a little scared about trying to build Inkscape.
Is there an extension or plug-in system in place? Or will I need to build Inkscape to test any changes I might make?
Yes. There isn't currently an API into Inkscape internals, we're waiting to use DOM for that (a standard API). What is most popular today is to use an external script (ie python) which gets passed the SVG document. This can be used for input/output formats or things that are on the Effects menu. Also, extensions can be built directly into Inkscape -- there are quite a few of these also.
--Ted
Ted,
Thank you for answering my question about inkscape's extension system.
You wrote: "What is most popular today is to use an external script (ie python) which gets passed the SVG document."
When you say "gets passed the SVG document", do you mean the document currently being manipulated in Inkscape?
Thanks,
Scott Huey
On 4/13/07, Ted Gould <ted@...11...> wrote:
On Thu, 2007-04-12 at 16:02 -0700, Redefined Horizons wrote:
I also thought I would find out if Inkscape had a plug-in or extension system just yet. If it did I thought I might take a stab at making small improvements to the program. I'm not an experienced C++ developer and I'm a little scared about trying to build Inkscape.
Is there an extension or plug-in system in place? Or will I need to build Inkscape to test any changes I might make?
Yes. There isn't currently an API into Inkscape internals, we're waiting to use DOM for that (a standard API). What is most popular today is to use an external script (ie python) which gets passed the SVG document. This can be used for input/output formats or things that are on the Effects menu. Also, extensions can be built directly into Inkscape -- there are quite a few of these also.
--Ted
On Mon, 2007-04-16 at 13:52 -0700, Redefined Horizons wrote:
Thank you for answering my question about inkscape's extension system.
No problem. We love questions and interested people.
You wrote: "What is most popular today is to use an external script (ie python) which gets passed the SVG document."
When you say "gets passed the SVG document", do you mean the document currently being manipulated in Inkscape?
So basically if you think of your script as something you'd run on the command line. So if wrote a little program, let's call it myext.py you could call it from the command line with something like this:
$ python myext.py
Inkscape does exactly that, but it saves the current document to a temporary file first. So it does this all behind the scenes:
$ python myext.py /tmp/ink-extER8we.svg
And expects your program to return the modified document to STDOUT. If you're interested in using python Aaron Spike has written a nice convenience library to help with this that is distributed with Inkscape.
Also (to answer your next e-mail) if the user has something selected in the document, that is also passed to the script like this:
$ python myext.py --id=nodeid45 /tmp/ink-extVER82ew.svg
I hope that helps.
--Ted
Hi, Ted,
One thing we should start addressing again is the launching of extensions from an embedded interpreter rather than shelling out. Embedding Python has improved a lot recently, so I suggest that we try to run extensions with that first. We can expose Inkscape internals rather cleanly now.
bob
On 4/17/07, Bob Jamison <rwjj@...127...> wrote:
One thing we should start addressing again is the launching of extensions from an embedded interpreter rather than shelling out. Embedding Python has improved a lot recently, so I suggest that we try to run extensions with that first. We can expose Inkscape internals rather cleanly now.
That would be cool. Do you already have some proof-of-concept script accessing internals? Will it run from the Scripts window? If yes, can we finally edit the message in that window to remove the "this window has no functionality" part?
Thanks!
bulia byak wrote:
On 4/17/07, Bob Jamison <rwjj@...127...> wrote:
One thing we should start addressing again is the launching of extensions from an embedded interpreter rather than shelling out. Embedding Python has improved a lot recently, so I suggest that we try to run extensions with that first. We can expose Inkscape internals rather cleanly now.
That would be cool. Do you already have some proof-of-concept script accessing internals? Will it run from the Scripts window? If yes, can we finally edit the message in that window to remove the "this window has no functionality" part?
Thanks!
That message is only displayed if neither --WITH-PYTHON nor --WITH_PERL are set. I would suggest that people only use --WITH-PYTHON for the time being, since we should probably get that one working well instead of trying both at once.
All the script does currently is show the About screen as a proof of concept. Python's stdout and stderr are redirected to the output textboxes.
Look at InkscapePython. You can see that I only have Inkscape, Document, Desktop, and DialogManager stubbed.
What we could use is two things:
1) Some help on launching python scripts internally as an alternative to shelling out.
2) Some fun ideas on what easily-bound things we would like to add initally. I have a difficult time having creative ideas, but this is a very creative crowd here. I know that we need to script both Repr and DOM, but those are a lot more work and will take a bit longer.
Script the Tracer? Script one or more of the drawing tools?
This is separate from the much larger DOM-JS binding stuff. But PyCxx is a good example of how to efficiently do the binding, which I will try to learn (steal) as much as I can. :-)
bob
On Tue, 2007-04-17 at 14:49 -0500, Bob Jamison wrote:
Look at InkscapePython. You can see that I only have Inkscape, Document, Desktop, and DialogManager stubbed.
I'm honestly not to thrilled about this. Any API that we choose here than has to be supported forever. I don't think we want to support the interfaces on those objects for that long.
DOM, we'll need to support that at the various levels also, but I'd really prefer to not have much of a custom API. Perhaps something generic like call effect? Pretty much anything can become an effect.
- Some help on launching python scripts internally as an alternative
to shelling out.
I'm for this, but I think that we don't need any internal APIs for that.
- Some fun ideas on what easily-bound things we would like to
add initally. I have a difficult time having creative ideas, but this is a very creative crowd here. I know that we need to script both Repr and DOM, but those are a lot more work and will take a bit longer.
I don't think we need to expose Repr at all. DOM should be sufficient for that.
This is separate from the much larger DOM-JS binding stuff. But PyCxx is a good example of how to efficiently do the binding, which I will try to learn (steal) as much as I can. :-)
I'm still a touch concerned about loosing SWIG, it means that we loose out on several of the languages that SWIG supports. I would hate to see us have to implement the same interface code to lots of different language interfaces. I don't think we should implement that functionality ourselves.
--Ted
On Tue, 17 Apr 2007 21:19:52 +0000, Ted Gould <ted@...11...> wrote:
On Tue, 2007-04-17 at 14:49 -0500, Bob Jamison wrote: I'm honestly not to thrilled about this. Any API that we choose here than has to be supported forever. I don't think we want to support the interfaces on those objects for that long.
Agreed.
I don't think we need to expose Repr at all. DOM should be sufficient for that.
We'll need to expose a few basic things, like completing undo transactions -- but obviously such things should be kept to a minimum right now, and that particular example could augment the DOM interface on Document with an additional interface implemented by the DOM document object. Also, we certainly do want SPDocument/undo transactions, not raw repr transactions.
I'm still a touch concerned about loosing SWIG, it means that we loose out on several of the languages that SWIG supports. I would hate to see us have to implement the same interface code to lots of different language interfaces. I don't think we should implement that functionality ourselves.
SWIG for multiple languages means pulling in a lot of (potentially mutually incompatible) runtimes, though. As a practical matter we need to pick either a single language (i.e. Python), or multiple languages on a single runtime (i.e. the JVM). So I don't think I'll mourn SWIG much.
-mental
MenTaLguY wrote:
SWIG for multiple languages means pulling in a lot of (potentially mutually incompatible) runtimes, though. As a practical matter we need to pick either a single language (i.e. Python), or multiple languages on a single runtime (i.e. the JVM). So I don't think I'll mourn SWIG much.
There are two main reasons I wanted to move away from SWIG, from actually giving it a try:
1. It doesn't do JS. There was a separate project that added that, but I think it's dead. 2. Its main task is to bind scripting languages to C. It doesn't understand C++ much. It can't handle overloading or templates, and even has problems with inheritance. We would need to artificially dumb-down the API specifically for SWIG, and not because of good design. I am using PyCxx, which is tiny, but it should be reasonably simple to convert to Boost's Python binder if we ever add Boost as a dependency (it's kinda huge). Doing it this way is just cleaner and more elegant. Does Boost have an ECMA binder?
bob
Ted Gould wrote:
I'm honestly not to thrilled about this. Any API that we choose here than has to be supported forever. I don't think we want to support the interfaces on those objects for that long.
True. If you look at InkscapeBinding.h/.cpp, you see the original interface/implementation I used to model the first binding stuff. We can actually define any interface model we want, and let the implementation touch the actual internal stuff. This could also be a step toward exposing the C++ interface that we talked about. But since our last attempts at an API fizzled out, I suggest we start small and let it flesh itself out in an orderly manner. And I also suggest that we use a KISS design and not try to make it an academic tour de force. People don't normally expect a frozen API until you slap a "1.0" on the thing. :-)
bob
On Tue, 2007-04-17 at 16:45 -0500, Bob Jamison wrote:
Ted Gould wrote:
I'm honestly not to thrilled about this. Any API that we choose here than has to be supported forever. I don't think we want to support the interfaces on those objects for that long.
True. If you look at InkscapeBinding.h/.cpp, you see the original interface/implementation I used to model the first binding stuff. We can actually define any interface model we want, and let the implementation touch the actual internal stuff. This could also be a step toward exposing the C++ interface that we talked about. But since our last attempts at an API fizzled out, I suggest we start small and let it flesh itself out in an orderly manner. And I also suggest that we use a KISS design and not try to make it an academic tour de force. People don't normally expect a frozen API until you slap a "1.0" on the thing. :-)
Well, I think that if we constantly try to keep the API simple and plan on it lasting forever, we'll be in a very good position when 1.0 happens.
--Ted
On Tue, 17 Apr 2007 12:32:15 -0500, Bob Jamison <rwjj@...127...> wrote:
One thing we should start addressing again is the launching of extensions from an embedded interpreter rather than shelling out. Embedding Python has improved a lot recently, so I suggest that we try to run extensions with that first. We can expose Inkscape internals rather cleanly now.
Something else we need to think about is whether we want to adopt a single language for scripting. I don't really like the idea of having several different runtimes involved in the same process, especially as I already know some of them don't play nicely together (Ruby is a particularly bad offender in that regard). It'd also mean an awful lot of stuff to ship for each language. I think this means we should focus on a single embedded runtime (for now, Python?), and jettison the rest (Perl).
Long-term, however, I think we should look at embedding the JVM and using a Java Python implementation instead of CPython. That will let us support other JVM-hosted languages as well, like Ruby and Javascript, without introducing additional runtimes.
-mental
participants (5)
-
Bob Jamison -
bulia byak -
MenTaLguY -
Redefined Horizons -
Ted Gould