I somehow missed this e-mail originally. My apologies for the late reply.
2009/7/25 Krzysztof Kosiński <tweenk.pl@...400...>:
The API looks like it is tied to the UI and uses global objects / state ... but changing the selection or any other UI element should not be necessary to execute operations. The downside is that it requires many changes on the Inkscape side ... The demos are exciting, but let's also think about doing it right from day 1 so that we won't have to turn around, waste time and break things later.
Regards, Krzysztof Kosiński
The original plan was to have two distinct interfaces. One directly tied to the UI that would require a SPDesktop, and one that would only require a SPDocument and would not show a window.
The second one was eventually put on hold (see application-interface in the documentation for details) because so much of the functionality was selection based.
Having a way of grouping objects other than selections was the initial plan, but for better or worse most of Inkscape's functionality is implemented through selections. To avoid them, lots of complex code that takes into account many different factors would have to be duplicated reducing maintainability.
The good news is that if Inkscape ever did refactor the way operations on multiple objects are performed, the dbus code could support that without much modification. It's just not something I could tackle this summer.
I didn't find this comment overly negative at all. It's a good point, though as Ted pointed out the direct relation to the UI does have it's advantages for certain users (which is why I wanted two separate interfaces.)
Thanks for the input, -Soren