On Tue, 28 Oct 2003, MenTaLguY wrote:
I've finished twiddling DNS for inkscape.org to point at our SF webspace, I think, though it'll take a while for things to settle down and propagate.
I've also added email aliases @inkscape.org for each of the currently added developers (y'all let me know if you object).
Cool, thanks!
Next up is probably getting the goodies in CVS. I'm strongly in favor of labeling the Sodipodi fork "hydra", but I'm not sure what to call the piece of code I'm working on. I'd originally been thinking "hercules", but maybe just "inkscape" is fine?
Since we cannot distribute a forked Sodipodi under the same name, I think we're going to need to rebrand it. It's logical to rebrand it as 'inkscape' since that will be the name of the project.
The next question we face is how to get from Point A to Point B. Knowing this will help determine what to call your codebase.
I've been through this process a few times before. There are several different approaches for doing this, most of which don't work very well.
At WorldForge we had a client called UClient that was written early in the project and that had been its first deliverable product. It was nifty that it worked, and it even had sound, animation, weather effects, etc. implemented, but by all opinions the codebase was sheer terror. Nearly all the developers who looked at it decided it would be "more time efficient" to start new clients from scratch. We gave them the go-ahead and all the support we could muster, but after 1-2 years they were nowhere close to replacing UClient. Starting over from scratch doesn't work well; it's harder than you think and more likely to fail spectacularly.
Having gone through all that, we chose a new approach. We took the existing UClient codebase and one of the prototypical but aborted clients that had been developed, and started slowly refactoring UClient to start to look like the model. Of course, UClient didn't end up exactly like the model, since people figured out new ideas along the way, but this approach allowed us to achieve the end result while always having a distributable, working copy of the code, that always did at least what the previous release did (more or less).
I can easily see us slip into the first approach with Inkscape, but feel strongly that the second approach, while less glamorous, would be much more likely to succeed.
This was why I was asking you about what you thought of recompiling Sodipodi into C++. That would be the logical first step; switch the compiler from gcc to g++ and then work on fixing all the compiler errors. Get it to compile and cut a release. Then pick some subsystem that's in dire need of objectification, take a look at your prototype, and figure out how to change the codebase to make it resemble your codebase, and do it in a way that doesn't require you to change very many files. Shoot for ambitious but incremental steps that refactor it into the direction you want it.
Also, is anyone any good with Doxygen? I'd like to start looking into that for both codebases...
I've used it before. The basic usage is extremely straightforward. For each function or class, put a comment ahead of it in the following style:
/** A Test class. * More details about this class. */
class Test { public: /** An example member function. * More details about this function. */ void example(); };
Note the double asterisks; that's what clues Docygen in.
The documents are created with a commandline like,
$ doxytag -t example.tag example/html
This turns into something like this:
http://www.stack.nl/~dimitri/doxygen/examples/example/html/class_test.html
There's several other commenting styles that work with doxygen. I recommend the above style for two reasons: It is identical to JavaDoc, and the /* */ style comments will work find in any C compiler.
There are good lengthier examples you should next look at, on http://www.stack.nl/~dimitri/doxygen/docblocks.html This includes demonstrating how to do references to other doc sections, parameters, and alternate commenting styles.
Bryce