On Mar 2, 2010, at 5:15 PM, Krzysztof Kosiński wrote:
Hello
I'd like to know the opinion of others: which of those projects would be the most beneficial in the long run and at the same time can be finished in the GSoC timeframe?
- Convert renderer to Cairo - drawing speedups.
There might be some issues with this one pending more than RGB support. At the moment Cairo is right in the middle of getting support for CMYK and N-Channel rendering and display. Since this is a *very* requested feature as far as Inkscape goes, and could move people away from other proprietary applications, it might be something to keep in mind.
Migrating to Cairo for RGB only might be good as long as care was taken to track the API changes going in on their side. Probably the deciding factor would be a good estimation of the level of effort to get our code tuned over. Perhaps Bulia has a good handle on this.
- C++ize the SP layer and make XML nodes private.*
This one might be very good. You've spotted a lot of what could be fixed here, including the reduction of the parallel trees. However, there are some *VERY* complex bugs hiding in all this (layer bugs abound caused by it), and the reach of such changes is extremely wide.
It would be great to get this in... but the scope might be a bit larger than a single person's GSoC work.
- Multi shape editing - ability to edit more than 1 shape (like
ellipse or star) at once, with extra features like resizing rectangles by dragging their edges.
This one sounds very promising. The scope seems fairly reasonable (can expand to include more if things are progressing well, etc.) and the end-user benefit seems quite clear.
- Remove livarot in favor of 2Geom, improving 2Geom where necessary
(e.g. boolops).
This one sounds like another great one to have completed. But would definitely need an assessment of scope by someone well grounded in that area.
*) When XML nodes are private, it's much easier to implement backwards compatibility - we just implement the reading of obsolete versions in the corresponding SP object.
Ooh, I'd *VERY* strongly recommend against that. It is basically the design pattern taken by Microsoft for the MS Word "format" and leads to all sorts of problems. Backwards compatibility is made much more difficult by such an approach.
A more effective architecture is to decouple the reading and writing from the internal storage format. Then it is quite trivial to read in various versions of data and also write them out. I've seen this over and over, and in many different languages.
BUT I would also strongly agree that moving away from exposing internals directly will make such compatibility much easier.
It's pretty much required to solve the problems with flowtext and markers on rect. The idea is to make the SP layer slightly more DOM-like so that it can be exported through D-Bus. It seems like the only way to seriously decruftize Inkscape, but I'm not sure if it's doable in 2 months. Maybe somebody has an idea for a project that could do it at least partially?
I'd love to see at least some of this done. However, in chasing down all the problems that sprung up in doing the layers and layer dialog it became clear that we have a bit to much cruft and copy-n-paste hardcoded directly implementation, etc. to make this a simple task.
Hmmm... one suggestion might be to take a pass cleaning up the raw C-struct direct access stuff we have littered about and replace that with more of a proper C++ approach with accessors and methods. Among other things this even mirrors the major change that the GTK+ team is introducing with GTK+ 3.x. But... off hand that does not seem to have a good scope for a GSoC project.