On Fri, 27 Feb 2004, Charles Goodwin wrote:

...

From the roadmap overview:

(http://www.inkscape.org/roadmap.php)

6. Create Plugin Architecture 0.40
   • This architectural change will establish a new mechanism for how features are added and maintained in the codebase.
7. New Features 0.41
   • Implement snap-to object, enhanced layer support, and boolean operations.
8. STL Architectural Change 0.42
   • Shift codebase to using STL for data structures.
   • Replace use of #defines and enums with hashmap lookups
9. Extract SVG Canvas into a library 0.43

Obviously I'm massively ignorant of the issues involved, but from what I can see milestones 6 and 7 are relatively independent of 6 and 9.

...

From a GO perspective, it would absolutely brilliant if you could bring

milestone 9 into milestone 6, the point at which you might start using libgoffice for the plugin handling. (And I personally hope you do because it will help make goffice more functional, featureful, and robust as well as give Jody a bit of help.)

The reason I bring this up is that the sooner the Inkscape SVG canvas is available, the sooner other applications (esp. GO apps) can organise themselves around incorporating it.

Hi Charles,

Thanks for the encouragement for the SVG Canvas extraction. This is something several folks have expressed interest in, for a variety of purposes, and we're really looking forward to achieving it.

In fact, a couple people (nathan and mental iirc) had worked on extracting the canvas into a reusable component last year, as an experiment, but found that due to the way the architecture was structured and interconnected, it was proving to be a thornier problem than one would expect. However, the experiment did illuminate what architectural changes they felt should be undertaken to move us in that direction. The results of this investigation is what set the ordering of this feature.

Now, since it's been a few months since we laid out that roadmap, I think we need to re-review the items on it and see if our ordering maps to reality, and adjust. But note that at the end of the day, the actual ordering is driven by when a developer gets the urge to do it. For instance, I had initially listed the boolean operations feature to be done further along in the future, but Fred showed up with a patch to implement it right when we started 0.37, so it got done much earlier than planned.

So my philosphy is to try to make the roadmap match what the developers work on, rather than vice versa, so it's more of a way to coordinate and track efforts than a way of controlling things to get done in a certain order. The way that things seem to get done quicker is to gain a teammember with a passion for implementing that feature, and encourage them to go ahead and do it.

So please keep your eye out for someone with that set of interests and if you find someone, encourage them our way. :-)

Bryce