Turn your development effort into Instant $$$!!
Hey all,
Looking to make some extra money?
Mark Shuttleworth, the guy who got to the ISS as a Soyuz Cosmonaut is a big Python fan. Seems he wants to fund the development of Python scripting of "OpenOffice, Abiword, Gnumeric, Agnubis, Sodipodi and other Gnome applications", among other things:
http://www.markshuttleworth.com/bounty.html
Worth a look, even if other things have to take first priority.
Truth, Mike S.
Maybe his foundation could fund the development of the python scripting feature for Inkscape we've discussed implementing?
Jon
On Wed, 2003-12-03 at 18:29, Michael D. Seymour wrote:
Hey all,
Looking to make some extra money?
Mark Shuttleworth, the guy who got to the ISS as a Soyuz Cosmonaut is a big Python fan. Seems he wants to fund the development of Python scripting of "OpenOffice, Abiword, Gnumeric, Agnubis, Sodipodi and other Gnome applications", among other things:
http://www.markshuttleworth.com/bounty.html
Worth a look, even if other things have to take first priority.
Truth, Mike S.
Jonathan Phillips wrote:
Maybe his foundation could fund the development of the python scripting feature for Inkscape we've discussed implementing?
It's funny, I was thinking about how to implement scripting this morning before I'd heard of the bounty...
I'll leave it to someone else now, as they have incentive to do it! :)
njh
On Thu, 4 Dec 2003, Nathan Hurst wrote:
Jonathan Phillips wrote:
Maybe his foundation could fund the development of the python scripting feature for Inkscape we've discussed implementing?
It's funny, I was thinking about how to implement scripting this morning before I'd heard of the bounty...
I'll leave it to someone else now, as they have incentive to do it! :)
I'd also love to see someone take this challenge on and implement it for Inkscape and/or Sodipodi. If anyone's interested, speak up, I think the rest of us would love to see the feature come to be.
Now, if no one wants to take it on individually, do we want to consider organizing an effort ourselves? E.g., we would create a requirements spec for the system defining our acceptance criteria and expectations, recruit a small team (2-3) developers to write the proposal, design spec, and do the implementation. They'd split the bounty and hold the responsibility for completing it, themselves.
Also, I notice that they did not specifically say they'd fund adding Python support to Sodipodi "and etc." but rather to write a spec for a universal scripting approach across multiple apps. So it might be hard at this point to make a strong enough proposal for this for Inkscape. This might be work-aroundable if the patch is submitted to both Inkscape and Sodipodi.
Another approach I've been kicking around is if we "stole" the plugin architecture/design from another project - Karbon14 has a plugin system, for example. Gaining the savings in design time would be the primary motivation, but conceivably the plugins could then be shareable or at least portable between the apps. No idea of the feasibility, though.
Bryce
On Wed, 3 Dec 2003 22:05:44 -0800 (PST) Bryce Harrington <bryce@...1...> wrote:
I'd also love to see someone take this challenge on and implement it for Inkscape and/or Sodipodi. If anyone's interested, speak up, I think the rest of us would love to see the feature come to be.
How about fixing up the DOM interface first. Then adding a scripting language is not a great deal more than adding bindings for the DOM methods and launching scripts.
On Wed, 2003-12-03 at 23:05, Bryce Harrington wrote:
Also, I notice that they did not specifically say they'd fund adding Python support to Sodipodi "and etc." but rather to write a spec for a universal scripting approach across multiple apps. So it might be hard at this point to make a strong enough proposal for this for Inkscape. This might be work-aroundable if the patch is submitted to both Inkscape and Sodipodi.
I got this same impression, so I think what they'd really like is Bonobo to be in all the applications, and Python wrappers for Bonobo (I think there are some, but I haven't looked). This way a script could use all those applications...
Another approach I've been kicking around is if we "stole" the plugin architecture/design from another project - Karbon14 has a plugin system, for example. Gaining the savings in design time would be the primary motivation, but conceivably the plugins could then be shareable or at least portable between the apps. No idea of the feasibility, though.
I was curious if we could write a little python script (mostly stealing code) using the Sketch stuff. Basically using the Sketch input plug-ins to read in a file, and then their output SVG plug-in to put it into Inkscape. Yeah, it would be a rather heavy way to get lots of input and output formats, but I think it would work.
The basic module architecture right now is derived from the Adobe Illustrator plug-in model. There are some optimizations and changes, but that's where most of the ideas come from. I had looked at others, but the Adobe one seemed the most mature (surprise), flexible and reasonable. I think the basic ideas of 'load, unload, prefs, execute' will work for just about anything in the future. But, there are lots of things that Adobe and others have done, that we'll need. The future is bright, and I'm wearing shades :)
--Ted
Ted Gould wrote:
The basic module architecture right now is derived from the Adobe Illustrator plug-in model. There are some optimizations and changes, but that's where most of the ideas come from. I had looked at others, but the Adobe one seemed the most mature (surprise), flexible and reasonable. I think the basic ideas of 'load, unload, prefs, execute' will work for just about anything in the future. But, there are lots of things that Adobe and others have done, that we'll need. The future is bright, and I'm wearing shades :)
One thing to remember about the Adobe model is that they don't want other people poking around in their code, whereas we are/should be quite happy with people adding anything they like. For example, Peter and I have been working on a new improved grids and guides system, currently written in python. We'd like to just plonk this into inkscape and see how it works before commiting to spending a few weeks petrifying it into C(++). There's no way we can do this currently using the modules code, because we need to do things like add new tools and catch all edit operations.
njh
On Fri, 2003-12-05 at 02:40, Nathan Hurst wrote:
Ted Gould wrote:
The basic module architecture right now is derived from the Adobe Illustrator plug-in model. There are some optimizations and changes, but that's where most of the ideas come from. I had looked at others, but the Adobe one seemed the most mature (surprise), flexible and reasonable. I think the basic ideas of 'load, unload, prefs, execute' will work for just about anything in the future. But, there are lots of things that Adobe and others have done, that we'll need. The future is bright, and I'm wearing shades :)
One thing to remember about the Adobe model is that they don't want other people poking around in their code, whereas we are/should be quite happy with people adding anything they like. For example, Peter and I have been working on a new improved grids and guides system, currently written in python. We'd like to just plonk this into inkscape and see how it works before commiting to spending a few weeks petrifying it into C(++). There's no way we can do this currently using the modules code, because we need to do things like add new tools and catch all edit operations.
I guess that's one of the reasons that I like the Adobe model, I don't think to write a module someone should HAVE to look at the code. They should be able to do everything externally from some well defined interfaces. Then, we only have to support those interfaces to remain compatible - we can change everything else ;)
I do believe that there needs to be a way to allow for modules to 'register' for events so that they get them. I don't know that I expect something as low level as the grid to be ever implemented as a module, but certainly someone should be able to write a tool or something like that.
--Ted
I fully agree with Ted on supporthing the adobe model. We should make it very easy for development of plugins for the system. What would be really cool, as we talked in relationship to the shuttleworth foundation money, is if we could get a python scripting environment that could be used across karbon14, sodi, Inkscape, and other apps. That way module development could be done in python.
But maybe scripting and modules should be separate? How does the gimp's script-fu and filters work?
I do think that both should be easy for mid-range users to develop scripts/modules for Inkscape.
Thoughts?
Jon
On Fri, 2003-12-05 at 07:48, Ted Gould wrote:
On Fri, 2003-12-05 at 02:40, Nathan Hurst wrote:
Ted Gould wrote:
The basic module architecture right now is derived from the Adobe Illustrator plug-in model. There are some optimizations and changes, but that's where most of the ideas come from. I had looked at others, but the Adobe one seemed the most mature (surprise), flexible and reasonable. I think the basic ideas of 'load, unload, prefs, execute' will work for just about anything in the future. But, there are lots of things that Adobe and others have done, that we'll need. The future is bright, and I'm wearing shades :)
One thing to remember about the Adobe model is that they don't want other people poking around in their code, whereas we are/should be quite happy with people adding anything they like. For example, Peter and I have been working on a new improved grids and guides system, currently written in python. We'd like to just plonk this into inkscape and see how it works before commiting to spending a few weeks petrifying it into C(++). There's no way we can do this currently using the modules code, because we need to do things like add new tools and catch all edit operations.
I guess that's one of the reasons that I like the Adobe model, I don't think to write a module someone should HAVE to look at the code. They should be able to do everything externally from some well defined interfaces. Then, we only have to support those interfaces to remain compatible - we can change everything else ;)
I do believe that there needs to be a way to allow for modules to 'register' for events so that they get them. I don't know that I expect something as low level as the grid to be ever implemented as a module, but certainly someone should be able to write a tool or something like that.
--Ted
Ted Gould wrote:
I guess that's one of the reasons that I like the Adobe model, I don't think to write a module someone should HAVE to look at the code. They should be able to do everything externally from some well defined interfaces. Then, we only have to support those interfaces to remain compatible - we can change everything else ;)
I do believe that there needs to be a way to allow for modules to 'register' for events so that they get them. I don't know that I expect something as low level as the grid to be ever implemented as a module, but certainly someone should be able to write a tool or something like that.
If your idea of a module is something which can only do a limited domain of operations, like plug-ins in gimp, then sure, but what if you are prototyping a new tool, such as warp to surface, or a new menu, such as 'animation timeline'. I think the latter is where open source can really shine.
njh
participants (6)
-
Bryce Harrington -
Ian Grant -
Jonathan Phillips -
Michael D. Seymour -
Nathan Hurst -
Ted Gould