On Sat, Sep 21, 2013 at 01:00:01AM +0200, Krzysztof Kosiński wrote:
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.
Mm, so it was sort of problem-of-opportunity because you were already engaged with the general area in question.
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?
- 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.
*Nod*
I recall the filter extension design concept was done extremely early in the project (like literally the second or third Inkscape release if I remember right). I'm impressed it's served duty so long, but it was always our intent to replace it with a proper extension API some day.
I've thought that there really should be at least two levels for the extension API. The first would be low level document model type stuff, like what the current filter system does relatively well. The other one would be a higher level one that encapsulates GUI functionality and provides a richer access to Inkscape's internal API.
- 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.
Way back in the day when we first did the original extension system, python was popular but we were mindful that so was perl and other scripting languages. So we felt that keeping things language-neutral would give some future-proofing. Indeed, Inkscape may have benefitted a lot from that decision in various ways, but clearly python has been the dominant language in practice.
DBus is really awesome, but agree it's not the right medium for designing an extension system around due to fundamental performance issues when using IPC.
Ultimately, what I'm imagining would be an extension system that would be document-specific in some fashion, so if you load an artistic-oriented document, you'll get one style of functionality/buttons, and if you're loading some 2D drafting-oriented document, you'd get some other style of GUI functionality.
Bryce