Sorry - to clarify, if it's not obvious - it was the second request that I am interested in. I don't know enough yet about the inkscape internals to help with any core code.

Thanks, Craig

On 21 August 2010 10:09, Craig Marshall <craig9@...400...> wrote:

I'd be interested in producing a custom extension for this problem. My way of approaching the problem might be slightly different from yours though (depending on whether inkscape stores the circle centrepoints and radii for a collection of merged circles, if not it might require that the circles are not merged before the extension is installed).

I'm a fairly seasoned programmer, but I'm very new to open source development, though I've been a user of open source software for years. I have made a couple of extensions for inkscape recently.

I don't think work for hire is against the philosophy of Free software or open source at all, if you have an unusual request that no-one else seems to need, then it's not going to write itself. Payment is still the number one way to get people to do things!

If you'd like to, we can continue to talk over private email.

Thanks, Craig

On 21 August 2010 08:52, Drechsel Wolf <edv-e@...2249...> wrote:

...

Hello everybody,

probabely there are lots of thoughts on this, so I'd be grateful for some hints:

I do have some very special wishes on inkscape developement:

# Improving the Mac OS X integration # implement a routine which counts the number of objects surrounded by another object: https://bugs.launchpad.net/inkscape/+bug/621627

Esp. the first has hardly moved forward during the last year, since I've started watching it. Is there a way of funding a special developement, which obviously does not attract a lot of attention?

Inkscape is free - alternatively I'd to pay 1000s of Euros for a "professional" product - with all its disacvantages. So I'd be happy to donate a number of Euros - and probabely some other people as well

• to pay somebody to get special work done, which would not be done

otherwise.

Is there a mechanism for that? - Could there be one? - Maybe some young person would be interested to earn a small sum, learn and get experienced - and get some work done within a professional environment? - Or is that idea completely against the spirit of open source?

Have a nice weekend!

Wolf

---

This SF.net email is sponsored by

Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

on the "funding inkscape developement" matter.

I agree for a form of professional support - Inkscape must have paid support at least for future DTP / Logo design / *** customers. With commercial support development speed can be much improved. Also a form of paid support for features on demand should exist.

Excepting speed rendering Inkscape is quite capable for DTP work and for sure he will be until press ready until Inkscape one point zero. I've recently compiled the GSOC code under Ubuntu and I see big speed improvements with Cairo enabled rendering. (Probably with Cairo 1.10 rendering speed will not be a problem anymore).

All in all, professional studios will not use Inkscape without tech-support. That mean they will not use Linux at full potential (just for rendering farms) - because Adobe will never port Creative suite on Linux. Linux world has a big gap on this area. And if Inkscape, GIMP, Scribus - will not accept that the paid technical support is a real need for designers / companies which don't like MS OS, no chance for Linux to become important on desktop.

+1 vote for Inkscape Foundation ;)

2010/8/21 Maximilian Albert <maximilian.albert@...1439...>:

Hi Craig,

...

I'd be interested in producing a custom extension for this problem. My way of approaching the problem might be slightly different from yours though (depending on whether inkscape stores the circle centrepoints and radii for a collection of merged circles, if not it might require that the circles are not merged before the extension is installed).

If I understand you correctly the solution you have in mind would require the outline to be a composition of circles. However, I can imagine many other use cases for this kind of request in slightly different circumstances where the outline is a general path (and the items to be counted may be arbitrary objects). Even though he implementation seems easiest at first if you restrict yourself to circles, I would very much recommend not to make any assumptions to that effect and keep the functionality as generic as possible. Of course it would be overkill to implement a test whether an arbitrary path contains another in your extension code, but have a look at lib2geom [1], the geometry library underlying Inkscape. I haven't checked recently but it might contain functions to test wether one path lies with the boundaries of another (or at least whether a given point lies within a path, which might already be enough for your purposes if you only take the centers of the small red dots into account). If it doesn't, this should definitely be implemented anyway. :) The libary also has Python bindings.

On a different note, instead of counting the items within the outline path directly, it might be better (as in: give more flexibility for other use cases) to provide an easy way to *select* them. See my comments on the bug report: https://bugs.launchpad.net/inkscape/+bug/621627

Hope this helps, Max

[1] http://lib2geom.sourceforge.net/

---

This SF.net email is sponsored by

Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

I'm sure the lib2geom library will help a great deal. That will save me wondering how to implement cubic bezier curve equations for paths constructed from joined circles!

I agree with everything you say - a general solution is definitely preferred. Also, making the program select the objects within the boundary shouldn't be any more difficult than just counting them (assuming the extension interface or SVG spec offers hooks for defining selections).

You mention that it could also be useful to filter the object types, I agree with that.

You also raise the question, what does it mean for an object to lie inside the path? It can be interpreted many ways as you started to explore:

a) Does the centrepoint of each inner object lie within the zero-width boundary of the outer object? b) Do the inner object's boundary lines lie entirely within the outer object's boundary line? Or: c) You could conceivably even take into account stroke-width as well; a 5px diameter circle might really be a 1px diameter circle with a 4px stroke width. d) ...I'm sure there are more ways of deciding.

I imagine Drechsel has a fairly specific use case in mind.

I see the attraction of creating a very general purpose extension to solve this, but my aim for now would be to come up with a solution that will solve the problem at hand. Clearly, if there are features that would otherwise require substantial rewriting of code or other duplication of effort (i.e. code for searching *all* paths, not just circles, if that's within my abilities), then it makes sense to make the extension do those things the first time round.

However, if there are ideas for even more general features that are not needed for this problem, and, equally importantly, that can also easily be added later (when and if there's a need or desire; e.g. filtering by object type, finer-grained options about where the contained objects lie), then I might leave those for later or for others to implement. I suppose it will depend on my own free time and enthusiasm too. If I still have time and energy left after the main problem is solved, then I may well be interested in writing these extra features. I just don't want to set up expectations for extras at this stage.

Thanks, Craig

On 21 August 2010 10:49, Maximilian Albert <maximilian.albert@...1439...> wrote:

Hi Craig,

...

I'd be interested in producing a custom extension for this problem. My way of approaching the problem might be slightly different from yours though (depending on whether inkscape stores the circle centrepoints and radii for a collection of merged circles, if not it might require that the circles are not merged before the extension is installed).

If I understand you correctly the solution you have in mind would require the outline to be a composition of circles. However, I can imagine many other use cases for this kind of request in slightly different circumstances where the outline is a general path (and the items to be counted may be arbitrary objects). Even though he implementation seems easiest at first if you restrict yourself to circles, I would very much recommend not to make any assumptions to that effect and keep the functionality as generic as possible. Of course it would be overkill to implement a test whether an arbitrary path contains another in your extension code, but have a look at lib2geom [1], the geometry library underlying Inkscape. I haven't checked recently but it might contain functions to test wether one path lies with the boundaries of another (or at least whether a given point lies within a path, which might already be enough for your purposes if you only take the centers of the small red dots into account). If it doesn't, this should definitely be implemented anyway. :) The libary also has Python bindings.

On a different note, instead of counting the items within the outline path directly, it might be better (as in: give more flexibility for other use cases) to provide an easy way to *select* them. See my comments on the bug report: https://bugs.launchpad.net/inkscape/+bug/621627

Hope this helps, Max

[1] http://lib2geom.sourceforge.net/

On 8/22/10, Dave Crossland wrote:

This mailing list can be used to find freelance developers, and www.kickstarter.com can be used to find people to pool money with.

It looks like we already have some sort of relationship with http://linuxfund.org

...

Or is that idea completely against the spirit of open source?

No, free software is about freedom, not price; and there are many businesses that are built around the GPL.

There is one tricky thing here, however. Once you have people working for money, it's important to maintain existing community of volunteers who might feel less motivated to work for free when there are people who want to works on things for money. Not many projects have such an experience, and not all projects that have it can call it positive.

Another thing is how you keep money flowing in. GIMP project seems to have this covered, but I simply have no idea if the income it has allows someone work full-time on the project, unless we are talking about third world rates. And note that Inkscape is less popular than GIMP which theoretically means less income.

So far for Inkscape project the only paid projects I know of are GSoC projects and Tav's work on the Text tool. GSoC projects are only partly successful, though we got some dedicated programmers from them like Johan, Maximilian or Krzysztof. Tav's project was very successful, albeit he was second programmer to work on it.

Also, the project's PayPal account is still locked (to the best of my knowledge), and nobody ever replied to the mail in this list that asked about http://inkscape.org/donate.php. To me it means that there is no person in the team who is in charge for financial side of things.

Once again, this is not to say that we don't need to grow into a commercially successful (or at least self-supporting) project. But first things first: we urgently need to get organized again.

Alexandre Prokoudine http://libregraphicsworld.org