My name is Soren Berg and I wanted to propose a possible Google Summer of Code project and see what you guys think.
I would like to use GSoC '09 to improve the scripting API of Inkscape.
This is an area that has seen some major changes over the last few years in terms of extension support and verb passing but I still believe there is room for improvement.
The extensions are very useful for making filters but don't (correct me if I'm wrong) really expose any of Inkscape's functionality. You need to use an entirely different set of tools to manipulate the XML data and pass it back.
The verbs are very useful for batch processing and similar tasks, but the fact that none of them take any parameters or return results means that they are not ideal for scripting or otherwise interacting with Inkscape in a more in-depth fashion.
I wrote a scripting console that exposed many Inkscape functions for programatically creating images and it was accepted for inclusion but it became harder and harder to support, largely because of the lack of any sort of API. It did show some very interesting benefits to controlling Inkscape programatically (like script-fu for the GIMP) though.
I know there is some work going on with a Java based API but it seems to be mostly stubs right now.
I could start working on this early as well since I have a job that wants to integrate software with Inkscape.
What do you guys think? Obviously I haven't fleshed out my plans very much, and that is because I want to get some general feedback on the concept first.
Thank you for reading, Soren Berg
On Sat, Mar 28, 2009 at 4:05 PM, Glimmer Labs <glimmer07@...400...> wrote:
I could start working on this early as well since I have a job that wants to integrate software with Inkscape.
What do you guys think? Obviously I haven't fleshed out my plans very much, and that is because I want to get some general feedback on the concept first.
I think this is a great idea overall, though it's not exactly my domain. But a way to pass parameters to verbs, as well as expose more things via verbs, would be great.
On Sat, Mar 28, 2009 at 11:05 PM, Glimmer Labs wrote:
I know there is some work going on with a Java based API but it seems to be mostly stubs right now.
I could start working on this early as well since I have a job that wants to integrate software with Inkscape.
What do you guys think? Obviously I haven't fleshed out my plans very much, and that is because I want to get some general feedback on the concept first.
What do you envision as final deliveries of this project?
Alexandre
What do you envision as final deliveries of this project?
Alexandre
I am still trying to work out the feasibility of various options, but hopefully a very minimal API along with a framework for expanding it.
One thing I would definitely have to work on (before the summer started, ideally) is making sure that the API is well designed and makes sense as a whole, even if I am only implementing a subset.
Some of the things I implemented when I worked on this before:
*Control the selection tool *Control the shapes tools (along with simplified versions that only take the most common parameters) *Cut/Copy/Paste/Delete selections *add or remove objects from selections, move selections etc.
even with only these functions I was able to write short scripts that generated very interesting fractal like images or morphed shapes into one another.
One thing in my favor is that Inkscape has a very straightforward image model, compared to the GIMP, so an API would not need the complexity of their PDB.
One potential hurdle is that I believe application scripting works best when it is interactive (i.e. not passed in on the command line.) This is especially important when you are trying to allow actual artists to use scripting to increase precision or or to automate or randomize highly repetitive tasks. They need to be able to move back and forth from programmatic control to manual control based on the suitability of each for the task at hand.
An added bonus would be compatibility with a standalone multi-language scripting console that I have been meaning to integrate, but have been hampered by the lack of a stable API.
Thank you for your help in this matter, Soren Berg
On Sat, 2009-03-28 at 20:26 -0500, Glimmer Labs wrote:
What do you envision as final deliveries of this project?
I am still trying to work out the feasibility of various options, but hopefully a very minimal API along with a framework for expanding it.
One thing I would definitely have to work on (before the summer started, ideally) is making sure that the API is well designed and makes sense as a whole, even if I am only implementing a subset.
I think that makes sense. One thing that I think would be interesting for this project is to use the new GObject introspection libraries that are being developed. This basically allows for a static API file to be built that there are language libraries that can pick it up. Basically by doing the effort for GObject introspection once, we can pick up Python and Javascript easily, but also other languages pretty quickly.
The difficult part becomes where to put the interpreters. And that's always what we've struggled with a little in the past. You really want to provide every language that anyone could develop in, but we don't want Inkscape linking to every interpreter that you can possibly think of. That would suck.
One of the things that Mental and I had discussed, which I think might also be interesting. Is the idea of making an API like this and exporting it over DBus. So we'd still be calling an external process, but giving it a DBus address and an object. Then it could do what ever it needed. This would also give the possibility of doing floating panels and other types of extension as well.
--Ted
On Sun, Mar 29, 2009 at 9:44 PM, Ted Gould <ted@...11...> wrote:
I think that makes sense. One thing that I think would be interesting for this project is to use the new GObject introspection libraries that are being developed.
One of the things that Mental and I had discussed, which I think might also be interesting. Is the idea of making an API like this and exporting it over DBus.
--Ted
I really like the idea of using DBus for the API. I've been looking into it and it seems like a really good solution. it might require work for the users of the API (having to develop an standalone application and make a DBus object) but it would be much simpler to develop and much more reasonable for a summer project. It also seems like a very good starting point. Even if it is relatively simple, it gets the functionality out there. I know of at least one application (the one I'm working on now) that could use it to allow Inkscape scripting in Scheme and Python (and more, soon.)
It is also my understanding that DBus can be connected to with python, so that gives us direct python control right there. Unless I am mistaken. That could make for very easy way to manipulate Inkscape. Write a Python script that connects to the bus, starts Inkscape if it is not already running (http://raphael.slinckx.net/blog/documents/dbus-tutorial), and calls methods in real time.
As far as GObjects go I have some experience building them, but my understanding of the introspection libraries is that they are relatively experimental, a word I don't like seeing in relation to tight coding deadlines. I also know that GObjects require a lot more code to set up and hence more time. That has to be weighed against the benefits of having GObjects versus C++ Objects.
I don't think I want to deal with introspection yet, but I could annotate it if I'm using GObjects, that would make it easier to add in that functionality later.
I would like to use DBus either way, though I might make that extended goal, just to be on the safe side.
What do you guys think? More long term expansion opportunities (GObject)? Or faster development time, and therefore a more fleshed out API and wider margins of error (C++ Objects)?
Any advice?
On Apr 1, 2009, at 1:05 PM, Glimmer Labs wrote:
I would like to use DBus either way, though I might make that extended goal, just to be on the safe side.
What do you guys think? More long term expansion opportunities (GObject)? Or faster development time, and therefore a more fleshed out API and wider margins of error (C++ Objects)?
Personally I have the impression that an API can use DBus as a transport, but that it should not be the "API" in and of itself.
Of course, once we have solid DBus on Windows things will go much quicker. However I do like it for a transport, and see it as far more viable than CORBA.
On Wed, Apr 1, 2009 at 9:51 PM, Jon A. Cruz <jon@...18...> wrote:
On Apr 1, 2009, at 1:05 PM, Glimmer Labs wrote:
Personally I have the impression that an API can use DBus as a transport, but that it should not be the "API" in and of itself.
Pardon my enthusiasm for the DBus idea. What I meant by "extended goal" is that I would first design, implement (a subset of), and test the API. Then, time permitting, I would add the DBus functionality that would bring the system to a reasonably usable state.
As far as Guile, Swig, etc. I believe that DBus gives us most of that since it is inter process communication and it doesn't really matter what is on the other end (say, a Python program or script.) Regardless, I believe that dealing with language bindings and linkings (however we decide to manage them) would be an extension to this summers project, otherwise it would be easy to bite off more than I could chew. For now I will leave that up to the users of the API.
I am very intrigued by the concept of using XForms. On one hand they seem like a potentially elegant solution. On the other hand, whether or not they could or should be used this way, they certainly are not usually used this way. Given the moderate information I was able to dig up about them I'm not sure that XForms would be the best choice for a student project, which should be on fairly solid ground in terms of probability of success.
Does anyone who has experience with XForms (or discussed it) have any advice about the feasibility of using them for a relatively short project?
Thanks for all the helpful comments, Soren Berg
On Apr 2, 2009, at 8:37 AM, Glimmer Labs wrote:
Pardon my enthusiasm for the DBus idea. What I meant by "extended goal" is that I would first design, implement (a subset of), and test the API. Then, time permitting, I would add the DBus functionality that would bring the system to a reasonably usable state.
Oh, no problem. You're in some good company with your enthusiasm.
As far as Guile, Swig, etc. I believe that DBus gives us most of that since it is inter process communication and it doesn't really matter what is on the other end (say, a Python program or script.) Regardless, I believe that dealing with language bindings and linkings (however we decide to manage them) would be an extension to this summers project, otherwise it would be easy to bite off more than I could chew. For now I will leave that up to the users of the API.
Yes. I think language bindings could be a later step.
First would be to figure out the *logical* objects involved, aspects, attributes, functionality, etc.
Then could come how to access those object and methods in a high level "API".
Then that API could be mapped to several transports, DBus being among them.
And finally other people can add language bindings on various sides of transports.
I am very intrigued by the concept of using XForms. On one hand they seem like a potentially elegant solution. On the other hand, whether or not they could or should be used this way, they certainly are not usually used this way. Given the moderate information I was able to dig up about them I'm not sure that XForms would be the best choice for a student project, which should be on fairly solid ground in terms of probability of success.
Does anyone who has experience with XForms (or discussed it) have any advice about the feasibility of using them for a relatively short project?
Well... I've done shipping hand-held apps with it, so am pretty comfortable with the scope.
XForms is not really a new thing in and of itself. Instead it is how to use existing technologies to achieve a nice effect.
First of all it is built on top of DOM. So you need to have a document object model. One good aspect is that SVG already has DOM bindings, etc. http://www.w3.org/TR/SVG/types.html#BasicDOMInterfaces
Then you get to point at things in such a tree via XPath
Then toss in DOM Events to get interactivity, change notifications, etc. http://en.wikipedia.org/wiki/DOM_Events
*Then* you can glue things up to actual UI widgets. One interesting point is that the current extension mechanism allows for parameters in declarative XML form, in line with how XPath sets things up.
So in the case of the existing UI, we have the external final part done, but not all the middle parts. For an SoC project one could do the same thing. That is, pick some subsets of immediate functionality, and just implement it in such a way so that later changes can bring in full DOM interaction, etc.
If nothing else, reading through XForms Essentials can help with various concepts that can map into other areas also. Again, since it uses standard things like DOM, DOM Events and XPath, one can gain insights for any applications of those. http://xformsinstitute.com/essentials/
This idea has now been submitted as a GSoC project under the name Inkscape API.
Thanks to everyone who helped me develop this proposal.
Aditional information, including: resume, regression testing proof of concept, recomondations, and some images created with my previous work on Inkscape can be found at http://www.cs.grinnell.edu/~bergsore/GSoChttp://www.cs.grinnell.edu/%7Ebergsore/GSoC Thank you for your time, Soren Berg
Ted Gould wrote:
I think that makes sense. One thing that I think would be interesting for this project is to use the new GObject introspection libraries that are being developed. This basically allows for a static API file to be built that there are language libraries that can pick it up. Basically by doing the effort for GObject introspection once, we can pick up Python and Javascript easily, but also other languages pretty quickly.
We would have to roll back most of the C++ conversion in order to do that, and go back to plain GObject. I don't think that's possible.
I think the best solution would be to use SWIG (an automated binding generator). Jon suggested using XForms over DBus, but I think that's just too complicated to be feasible.
Regards, Krzysztof Kosiński
Krzysztof Kosiński wrote:
Ted Gould wrote:
I think that makes sense. One thing that I think would be interesting for this project is to use the new GObject introspection libraries that are being developed. This basically allows for a static API file to be built that there are language libraries that can pick it up. Basically by doing the effort for GObject introspection once, we can pick up Python and Javascript easily, but also other languages pretty quickly.
We would have to roll back most of the C++ conversion in order to do that, and go back to plain GObject. I don't think that's possible.
I think the best solution would be to use SWIG (an automated binding generator). Jon suggested using XForms over DBus, but I think that's just too complicated to be feasible.
I'm certainly no expert but I found that SWIG was mightily unhelpful for exposing C++ code written in true C++ style. For py2geom we chose Boost.Python. I was very impressed at how easily it was to translate C++ thoughts into python thoughts with Boost. But unfortunately I think Boost remains python only. What I mean to say is that I have some reservations about how far SWIG can take you.
Aaron Spike
On Apr 1, 2009, at 5:55 PM, Krzysztof Kosiński wrote:
I think the best solution would be to use SWIG (an automated binding generator). Jon suggested using XForms over DBus, but I think that's just too complicated to be feasible.
Unless you've actually tried an implementation, please don't say that something is too complicated.
One of the key things about XForms is that it is *simple*, not complicated. And uses DOM and XPath, which already live in the SVG world.
I've also worked over the details with others, such as the Scribus developers who did their plugin support, and he had said that not only was it a feasible solution, it actually sounded like a better solution. (That is, not only *could* one use it for that, one probably *should* use it for that)
Jon A. Cruz wrote:
Unless you've actually tried an implementation, please don't say that something is too complicated.
I guess you're right, I didn't implement anything like this before, and frankly despite your explanations I still have only a faint idea of how this all is actually going to work, so I'll wait until I understand it better. (have to read more on DOM and XForms)
Regards, Krzysztof Kosiński
participants (7)
-
Aaron Spike -
Alexandre Prokoudine -
bulia byak -
Glimmer Labs -
Jon A. Cruz -
Krzysztof Kosiński -
Ted Gould