J.B.C.Engelen@...1578... wrote:
Hi all!
I just heard the great news! Thanks for giving me this opportunity again! Congratulations Felipe, Marco, Jasper and Max!
Indeed, and to you as well.
Special note to Max and Marco: since you do geometry things, I'd be happy to work more closely with you if possible and desired :) To Jasper: is it okay if I bug you about path tests? :)
Sure :)
Really excited by the project ideas that were accepted! Now, to the topic of this mail: GSoC branches, yes/no.
I will be doing under-the-hood refactoring, and I am thinking about whether or not to work in my own svn branch. Pros: I can break builds with partial commits and/or make bad bad bugs. Cons: I won't discover bad bugs.
I'd like to work in trunk, because of the bugs issue and because it will force me to immediately handle new code by others. Moreover, I will be forced to make changes that build and function and won't be drawn into making a half-way solution that will not work at the end of GSOC.
Sounds sensible to me. After all, when refactoring you should indeed be aiming to keep the code working after every step.
BTW, I had a look at path handling in Inkscape recently (because of my relative paths patch) and I encountered the following parts of the code that deal with paths (you probably already know most, if not all, of this, but I thought I'd list it anyway, just in case): - NR::Path, libnr/n-art-bpath - libnr/n-art-bpath-2geom - svg/gnome-canvas-bpath-util, svg/svg-path, svg/path-string - SP::Curve - Geom::Path - livarot Path(Descr) - dom/svgtypes SP::Curve, NR::Path and Geom::Path probably have the most functionality in common. The livarot Path(Descr) class(es) are also similar, but they also have a lot of rendering related functionality. n-art-bpath-2geom and the svg/* files on the other hand all do something with parsing/serializing. And dom/svgtypes is probably again a completely different story, but looking at the file(s) I do wonder whether it couldn't reuse a bit more (in general, not just the path related parts).