2013/9/20 Bryce Harrington <bryce@...961...>:
Correct me, but I'll assume your motivation wasn't merely/purely to earn the cash. Did the $100 serve more of a symbolic purpose to you? Like, just as a marker of that user's desire for the fix? Like, that you knew the effort would be more appreciated than usual. Or did you feel a sense of principle that users should be able to pay for bugs, and did it to help further that ideal? Or some other reason?
I rewrote the rendering code as part of the GSoC 2011 project. It occured to me that this bug could be fixed fairly easily while doing that. The fact that there was a reward did not influence me all that much, though of course it did cause me to pay a little more attention and put in some extra effort to backport the fix to the stable branch.
Nice. I agree there's a lot of potential in Inkscape that could be tapped if it catered better to use cases beyond just art. What do you think would need to change in the extension API design to make these types of uses more feasible?
1. More comprehensive extension model. Currently it is not possible to implement a new object type or a tool in an extension; we are limited to a simple filter model. There is no access to Inkscape's API, and everything has to be reimplemented on the filter side.
2. Real script bindings, designed using the "worse is better" principle of Unix. We currently have a DBus binding, which has some nice features (e.g. language neutrality), but is not very practical or used a lot. We also can't use it for anything even remotely performance-sensitive due to the IPC overhead. Scripting could become a lot more practical if we provided a conventional binding to Python, used it internally to implement high-level features, and provided a scripting console where you can execute commands in the same way as in the interactive Python interpreter. gedit has something similar. In the extreme case, all non-UI functionality of Inkscape could eventually become a library with a Python binding.
Regards, Krzysztof