Which GSoC project would do the most good?
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?
1. Convert renderer to Cairo - drawing speedups. 2. C++ize the SP layer and make XML nodes private.* 3. 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. 4. Remove livarot in favor of 2Geom, improving 2Geom where necessary (e.g. boolops).
*) 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. 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?
Regards, Krzysztof
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.
W dniu 3 marca 2010 03:40 użytkownik Jon Cruz <jon@...18...> napisał:
*) 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.
Before you said that separating the XML <-> SP transformation from SPObjects into some external entity is bad. Now you say that leaving it in SPObjects is bad. I'm somewhat confused :)
"Making XML private" doesn't mean removing all access to it. The SPObject could still access its XML representation directly, and the "repr" variable wouldn't go away, so there still would be two more-or-less parallel trees. The undo stack would still have access to the XML tree, as well as a few other things that work better at the XML level. But all "semantic" operations, like pasting objects or modifying their shape, would work on the semantic tree (SP) using new, semantic methods like "pasteObjects()" or "setLayer()". It would also be possible for the SP hierarchy not to match the XML hierarchy (for example when svg:switch elements are present). This way we can change the XML representation easily, because we only need to modify the affected SPObjects.
Regards, Krzysztof
On Mar 4, 2010, at 4:50 AM, Krzysztof Kosiński wrote:
W dniu 3 marca 2010 03:40 użytkownik Jon Cruz <jon@...18...> napisał:
*) 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.
Before you said that separating the XML <-> SP transformation from SPObjects into some external entity is bad. Now you say that leaving it in SPObjects is bad. I'm somewhat confused :)
No, that's not directly what I was talking about.
The problem is in making each and every object responsible for its own serialization, especially when it comes to backwards compatibility. That was the immediate danger I was warning of.
It's a bit quicker to implement initially, but as things progress it starts to bog down. It's also less appropriate for a solution where one group is responsible for all the code involved. In practice I've seen this bite projects in under six months.
participants (2)
-
Jon Cruz -
Krzysztof Kosiński