2015-11-12 21:45 GMT+01:00 Papoj Thamjaroenporn <pt2277@...3110...>:
Why is SPKnot named with the SP prefix? From SPObject documentation, all SPObject is supposed to be representable as a node in SVG. There is no notion of “knot” in SVG 2 as far as I know, and the class didn't even inherit SPObject.
It's because SPKnot is not an SPObject. It's purely an UI element. and does not exist at the document level. SP is a prefix for "Sodipodi", the former name of Inkscape, and it was used for all GObject classes, not just those inherited from SPObject.
In terms of Model-View-Controller design pattern, I see SPKnot as the Model and KnotHolderEntity as the Controller, handling the Model creation and events handling. But instead, event handling resides partly in SPKnot itself and partly in KnotHolder, which confuses me in terms of the design of these classes.
SPKnot and SPKnotHolderEntity exist only because back when the original Sodipodi code was written, creating a derived class in GObject involved writing tons of boilerplate. That's why each type of knot is not a distinct class, but a generic instance of SPKnot that differs only by what signal handlers it has attached. You can see PathManipulator and the Inkscape::UI::Node hierarchy for my more modern take on this, which uses virtual functions instead of signals. I wanted to eventually port everything to this new pattern, but my master's thesis was about a completely different area of code.
Unfortunately, there are several things in Inkscape which are similarly poorly designed. There are also at least a few cases where people who added new features did not fully understand the existing, reasonably good design due to documentation deficiencies and coded around it, resulting in huge kludges - it's the main reason why our dev cycles take so long.
Best regards, Krzysztof