Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
Here's also a bunch of good ideas Krzysztof posted several weeks back. Some of these may be a little too ambitious to do in a summer so would need scoped down.
1. Improve Icon Cache Convert the icon cache (icon.cpp) to create the PNGs with a directory structure and index file matching the icon theme specification. Use this to get rid of customized classes InkAction, SPIcon, and so on.
2. Remove dom/ directory This directory contains strange code which is barely used. The only class which is actually used is the URI class.
3. SAX parser Convert the current document parser from DOM to SAX, so that it creates our XML tree right away, instead of creating the libxml2 DOM tree, creating our tree to match it, then freeing the libxml2 tree. This should improve performance and allow more robust fixes for some problems.
4. Rewrite of Geom::PathVector and Geom::Path Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves. Move the copy-on-write idiom to the PathVector object, rather than using it in the Path. Investigate whether it is possible to store subpath data in a more compact way and make the Curve objects only convenience facades. Right now, if the path has only linear segments, every point is stored twice. Apply the following renames to match SVG terminology: Path -> Subpath PathVector -> Path
5. Boolean operations and stroking Add methods to PathVector objects: a) Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. b) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation. c) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
6. Renderer improvements This is a big task which has several sub-tasks: a) Unify the interactive and non-interactive renderers. (It would be desirable to have one codebase, but we need to investigate a little more whether this is practical.) b) Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL. c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would render Beziers using this method: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Investigate whether this generalizes to S-basis and circular arcs. Since the described method does not handle stroking, this work depends on 5. Also check how OpenGL path rendering is implemented in Qt, since apparently the performance there is very good. http://zrusin.blogspot.com/2011/09/nv-path-rendering.html
7. Typed XML tree Improve XML tree so that it can store some attributes in parsed, binary form. The main target of this are the data URIs used to embed images, which could be stored as binary data only. This work should be done after completing task 3 (SAX parser), as this will make it easier.
8. Shape manipulators The idea here is to rewrite shape tools in the same paradigm as the node tool. Instead of storing all information about the shape in knots which differ only by their callbacks, allow to store information in a higher-level manipulator object. This would enable things like dragging the side of a rectangle and consistent outlining / update preferences for all shapes.
9. Improve the performance of layer visibility Right now, toggling layer visibility causes massive changes in the display tree, because the entire toggled layer is invalidated at the XML level. This results in very bad performance for an action which should nearly instantaneous. Improve the control flow so that only the visibility of the object representing the layer is turned off, but the remainder of the display and object tree is leaved alone.
10. Common build system for all platforms Migrate the build system to Waf for all platforms. Alternatively, if there are important technical reasons why Waf is not suitable, port all necessary features to the CMake build system and remove Autotools.
11. Remove SPCurve SPCurve is a thin wrapper around Geom::PathVector which exists for historical reasons. Its functionality should be added to PathVector, and SPCurve should be purged.
12. Use a different data structure for Inkscape::Selection Inkscape::Selection currently uses GSList as its data structure. This is suboptimal, since a very common operation is checking whether some object is selected. Change Inkscape::Selection so that its underlying structure is a boost::multi_index container which implements the same semantics as Java's LinkedHashSet.
13. Remove all use of GList and GSList These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers.
14. Box blur Currently we always use a very accurate method to compute the Gaussian blur filter. Add an alternate method which approximates Gaussian blur using three stacked box blurs (simple averages). This is detailed in the SVG 1.1 SE specification.
15. GTK3 on Windows Rebuild the Windows devlibs so that they contain GTK3. Make the Windows port work with them, possibly sending the appropriate patches to the GTK maintainers.
16. Migrate argument parsing to GOption and remove the dependency on popt Write test cases for this bug, so that the patches can be accepted into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=522131 If this proves hard, simply apply the patch to the devlibs. Once this is done, port argument parsing to GOption.
17. Extension system improvements Refactor the extension API. Clean up the kludgy class hierarchy, possibly using multiple inheritance. Use GInputStream and GOutputStream as parameters instead of file paths, so that things like the clipboard can have
18. Robust ID handling Currently ID clash resolution is implemented as a giant switch over object types, listing every possible dependency. Replace this with virtual methods on objects, which provide information on what each object refers to. Improve behavior when a dependency of an object is deleted, and when IDs are changed / deleted from the XML editor.
A great list, thanks Krysztof! (and Bryce). A lot of these tasks fall well short of the effort for a SoC, and they have dependencies between them which mean that allocating them could tie one student's success to another (a bad idea I think).
Here's a crazy idea: run this list (or some portion of it) as a kanban style development process: https://en.wikipedia.org/wiki/Kanban_(development)
We would take a few of the students who were keen to be involved and they would all work off the same kanban queue as a team. Assessment would be around how many tasks they completed (we would need to specify upfront the expected effort for each task and how many effort would be considered a pass), and how they worked together to complete the list. As new work becomes apparent, it is also added to the queue and the team is responsible for prioritising the work. Team work is a very valuable skill for software development, and the siloed project effort typical of gsoc doesn't lead to strong team work.
njh
On Mon, Feb 24, 2014 at 11:51:29PM -0800, Bryce Harrington wrote:
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
Here's also a bunch of good ideas Krzysztof posted several weeks back. Some of these may be a little too ambitious to do in a summer so would need scoped down.
- Improve Icon Cache
Convert the icon cache (icon.cpp) to create the PNGs with a directory structure and index file matching the icon theme specification. Use this to get rid of customized classes InkAction, SPIcon, and so on.
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
- SAX parser
Convert the current document parser from DOM to SAX, so that it creates our XML tree right away, instead of creating the libxml2 DOM tree, creating our tree to match it, then freeing the libxml2 tree. This should improve performance and allow more robust fixes for some problems.
- Rewrite of Geom::PathVector and Geom::Path
Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves. Move the copy-on-write idiom to the PathVector object, rather than using it in the Path. Investigate whether it is possible to store subpath data in a more compact way and make the Curve objects only convenience facades. Right now, if the path has only linear segments, every point is stored twice. Apply the following renames to match SVG terminology: Path -> Subpath PathVector -> Path
- Boolean operations and stroking
Add methods to PathVector objects: a) Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. b) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation. c) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
- Renderer improvements
This is a big task which has several sub-tasks: a) Unify the interactive and non-interactive renderers. (It would be desirable to have one codebase, but we need to investigate a little more whether this is practical.) b) Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL. c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would render Beziers using this method: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Investigate whether this generalizes to S-basis and circular arcs. Since the described method does not handle stroking, this work depends on 5. Also check how OpenGL path rendering is implemented in Qt, since apparently the performance there is very good. http://zrusin.blogspot.com/2011/09/nv-path-rendering.html
- Typed XML tree
Improve XML tree so that it can store some attributes in parsed, binary form. The main target of this are the data URIs used to embed images, which could be stored as binary data only. This work should be done after completing task 3 (SAX parser), as this will make it easier.
- Shape manipulators
The idea here is to rewrite shape tools in the same paradigm as the node tool. Instead of storing all information about the shape in knots which differ only by their callbacks, allow to store information in a higher-level manipulator object. This would enable things like dragging the side of a rectangle and consistent outlining / update preferences for all shapes.
- Improve the performance of layer visibility
Right now, toggling layer visibility causes massive changes in the display tree, because the entire toggled layer is invalidated at the XML level. This results in very bad performance for an action which should nearly instantaneous. Improve the control flow so that only the visibility of the object representing the layer is turned off, but the remainder of the display and object tree is leaved alone.
- Common build system for all platforms
Migrate the build system to Waf for all platforms. Alternatively, if there are important technical reasons why Waf is not suitable, port all necessary features to the CMake build system and remove Autotools.
- Remove SPCurve
SPCurve is a thin wrapper around Geom::PathVector which exists for historical reasons. Its functionality should be added to PathVector, and SPCurve should be purged.
- Use a different data structure for Inkscape::Selection
Inkscape::Selection currently uses GSList as its data structure. This is suboptimal, since a very common operation is checking whether some object is selected. Change Inkscape::Selection so that its underlying structure is a boost::multi_index container which implements the same semantics as Java's LinkedHashSet.
- Remove all use of GList and GSList
These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers.
- Box blur
Currently we always use a very accurate method to compute the Gaussian blur filter. Add an alternate method which approximates Gaussian blur using three stacked box blurs (simple averages). This is detailed in the SVG 1.1 SE specification.
- GTK3 on Windows
Rebuild the Windows devlibs so that they contain GTK3. Make the Windows port work with them, possibly sending the appropriate patches to the GTK maintainers.
- Migrate argument parsing to GOption and remove the dependency on popt
Write test cases for this bug, so that the patches can be accepted into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=522131 If this proves hard, simply apply the patch to the devlibs. Once this is done, port argument parsing to GOption.
- Extension system improvements
Refactor the extension API. Clean up the kludgy class hierarchy, possibly using multiple inheritance. Use GInputStream and GOutputStream as parameters instead of file paths, so that things like the clipboard can have
- Robust ID handling
Currently ID clash resolution is implemented as a giant switch over object types, listing every possible dependency. Replace this with virtual methods on objects, which provide information on what each object refers to. Improve behavior when a dependency of an object is deleted, and when IDs are changed / deleted from the XML editor.
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2014-02-25 17:33 GMT+01:00 Nathan Hurst <njh@...1927...>:
Here's a crazy idea: run this list (or some portion of it) as a kanban style development process: https://en.wikipedia.org/wiki/Kanban_(development)
We would take a few of the students who were keen to be involved and they would all work off the same kanban queue as a team. Assessment would be around how many tasks they completed (we would need to specify upfront the expected effort for each task and how many effort would be considered a pass), and how they worked together to complete the list. As new work becomes apparent, it is also added to the queue and the team is responsible for prioritising the work. Team work is a very valuable skill for software development, and the siloed project effort typical of gsoc doesn't lead to strong team work.
That's true, but the rules for GSoC are quite restrictive when it comes to teamwork - I'm fairly sure that joint applications (e.g. 3 students applying to participate in this model) are not allowed at all.
A safer bet would be to merge some of the items into larger projects.
Regards, Krzysztof
On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosiński <tweenk.pl@...2179......>wrote:
That's true, but the rules for GSoC are quite restrictive when it comes to teamwork - I'm fairly sure that joint applications (e.g. 3 students applying to participate in this model) are not allowed at all.
This is correct. It would definitely not be allowed. They require very clear and obvious separation of work. My guess is that it's to ensure that each student is doing what they are supposed to and that they are not subject to failure due to shortcomings imposed by other students.
A safer bet would be to merge some of the items into larger projects.
If someone with a good sense of which ones would be appropriately combined would be willing to do so and add them to http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code#Suggested_Idea... would be greatly appreciated.
Cheers, Josh
On Tue, Feb 25, 2014 at 10:24:45AM -0800, Josh Andler wrote:
On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosi??ski <tweenk.pl@...400...>wrote:
That's true, but the rules for GSoC are quite restrictive when it comes to teamwork - I'm fairly sure that joint applications (e.g. 3 students applying to participate in this model) are not allowed at all.
This is correct. It would definitely not be allowed. They require very clear and obvious separation of work. My guess is that it's to ensure that each student is doing what they are supposed to and that they are not subject to failure due to shortcomings imposed by other students.
The whole point of kanban is that each task is self contained. It's easy to assess what each student has done, look at the bzr logs, look at the tasks undertaken, look at their report. Students can't affect each other, because at the frontier all the tasks are independant.
njh
On Tue, Feb 25, 2014 at 5:06 PM, Nathan Hurst <njh@...1927...> wrote:
The whole point of kanban is that each task is self contained. It's easy to assess what each student has done, look at the bzr logs, look at the tasks undertaken, look at their report. Students can't affect each other, because at the frontier all the tasks are independant.
The way you had said it earlier, you had mentioned they would work off the same kanban queue as a team. The students are supposed to have firm proposals outlining what they will specifically accomplish and what the corresponding timeline looks like. Because of this, it's not really possible to have multiple students working from a pool of tasks to be completed.
Honestly, I like your idea, however I don't believe there is a way to achieve this with GSoC that Google would approve of.
Cheers, Josh
On Wed, Feb 26, 2014 at 12:06:19PM +1100, Nathan Hurst wrote:
On Tue, Feb 25, 2014 at 10:24:45AM -0800, Josh Andler wrote:
On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosi??ski <tweenk.pl@...400...>wrote:
That's true, but the rules for GSoC are quite restrictive when it comes to teamwork - I'm fairly sure that joint applications (e.g. 3 students applying to participate in this model) are not allowed at all.
This is correct. It would definitely not be allowed. They require very clear and obvious separation of work. My guess is that it's to ensure that each student is doing what they are supposed to and that they are not subject to failure due to shortcomings imposed by other students.
That, certainly. Also, whenever there are multiple pieces being developed in parallel it requires a high degree of communication to ensure both projects end up fulfilling their requirements in a compatible fashion.
The whole point of kanban is that each task is self contained. It's easy to assess what each student has done, look at the bzr logs, look at the tasks undertaken, look at their report. Students can't affect each other, because at the frontier all the tasks are independant.
When I was doing development on Launchpad we used Kanban, so I'm reasonably familiar with the process. But it's nothing magical, it is just a way to organize and coordinate sequential interdependent tasks. It still requires a fair bit of upfront planning and coordination. It's like our traditional Roadmap system on steroids (I bet we could even implement Kanban *within* Inkscape with a bit of coding if we wanted.)
The team I was on had only 6 members, and frankly Kanban was a bit overkill for us. I think it's best suited for larger teams. Or maybe teams with finer grained tasks than we had, or that require more intensive team coordination.
So, I would love to play with Kanban more in team coordination, but I think for GSoC even if we did have 2-3 students working together I'm skeptical it would help all that much.
Bryce
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
That's worth knowing, I'll hack that up in my branch as I add the data uri support.
Martin,
On Feb 25, 2014, at 8:58 AM, Martin Owens wrote:
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
That's worth knowing, I'll hack that up in my branch as I add the data uri support.
Actually the intent of this one had been explained to others in the past. The dom directory was done in preparation of improving the extension system by providing a live DOM interface to plugins. We've even had members of the SVG and XML committees review and endorse the approach.
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
Does this mean uri.cpp / uri.h should be depricated? Should uri.cpp shift from using libxml to dom? What does the css parsing mean for libcroco?
Why do we have a giant blob of code, shouldn't it be a library that many people could take advantage of?
Thank fluctuations I put it in a branch though.
Martin,
The dom folder is compilable into a shared object without problems. Did Bob write the whole thing by himself? Parts of the code look generated somehow, e. g. http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/dom/ cssreader.cpp Is there any documentation or website about it?
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Martin Owens [mailto:doctormo@...400...] Gesendet: Mittwoch, 26. Februar 2014 17:54 An: Jon Cruz Cc: Inkscape Devel List; Inkscape User Community Betreff: Re: [Inkscape-devel] URI
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
Does this mean uri.cpp / uri.h should be depricated? Should uri.cpp shift from using libxml to dom? What does the css parsing mean for libcroco?
Why do we have a giant blob of code, shouldn't it be a library that many people could take advantage of?
Thank fluctuations I put it in a branch though.
Martin,
---------------------------------------------------------------------------- -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 26-2-2014 17:54, Martin Owens wrote:
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
This code has not been worked on 4.5 years and has since been a maintenance burden. Over the years (!), bit-by-bit, files have been removed from /src/dom. From my point of view, this code is definitely on its way out.
If anyone wants to work on this again, look it up in the history. If there is some info on this in our wiki, one could add a small note saying that there once was some code out there.
-Johan
On Wed, Feb 26, 2014 at 07:23:04PM +0100, Johan Engelen wrote:
On 26-2-2014 17:54, Martin Owens wrote:
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
This code has not been worked on 4.5 years and has since been a maintenance burden. Over the years (!), bit-by-bit, files have been removed from /src/dom. From my point of view, this code is definitely on its way out.
If anyone wants to work on this again, look it up in the history. If there is some info on this in our wiki, one could add a small note saying that there once was some code out there.
+1
Sounds like this is aiming to solve something we definitely need, but is an unfinished implementation, and without a design or architecture or roadmap written down it'll be hard for someone to pick it up and finish it. Best to move it out of the codebase - it can be reintroduced if/when it's more functionally relevant.
I do think we need to re-engineer how extensions work, and a DOM would be very nice for a number of reasons, but this is something we should focus on tackling in a future release.
Is there any chance that removing the dom/ dir might cause unexpected bugs? If so, let's postpone dropping it until after we're done with the release.
Bryce
On Thu, 2014-02-27 at 00:47 -0800, Bryce Harrington wrote:
Is there any chance that removing the dom/ dir might cause unexpected bugs? If so, let's postpone dropping it until after we're done with the release.
Not really. There's only two things to check and if we can find domain experts who know those areas, they could test them quite quickly.
I'll keep the branch separate, but if someone wants to merge in those changes; it'd be a real help.
Martin,
On Feb 27, 2014, at 12:47 AM, Bryce Harrington wrote:
On Wed, Feb 26, 2014 at 07:23:04PM +0100, Johan Engelen wrote:
On 26-2-2014 17:54, Martin Owens wrote:
On Wed, 2014-02-26 at 08:32 -0800, Jon Cruz wrote:
A better task might be to follow-up on Bob's work with the next step and get the DOM exposed.
Sounds like we were all on the wrong page with this one. Several developers seemed to think dom was on it's way out.
This code has not been worked on 4.5 years and has since been a maintenance burden. Over the years (!), bit-by-bit, files have been removed from /src/dom. From my point of view, this code is definitely on its way out.
If anyone wants to work on this again, look it up in the history. If there is some info on this in our wiki, one could add a small note saying that there once was some code out there.
+1
Sounds like this is aiming to solve something we definitely need, but is an unfinished implementation, and without a design or architecture or roadmap written down it'll be hard for someone to pick it up and finish it. Best to move it out of the codebase - it can be reintroduced if/when it's more functionally relevant.
I do think we need to re-engineer how extensions work, and a DOM would be very nice for a number of reasons, but this is something we should focus on tackling in a future release.
Is there any chance that removing the dom/ dir might cause unexpected bugs? If so, let's postpone dropping it until after we're done with the release.
It does sound like the good choice at the moment. As long as it has been considered and we've seen that alternate approaches will be better, that is a good set for the chopping block.
2014-02-26 17:32 GMT+01:00 Jon Cruz <jon@...18...>:
On Feb 25, 2014, at 8:58 AM, Martin Owens wrote:
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
That's worth knowing, I'll hack that up in my branch as I add the data uri support.
Actually the intent of this one had been explained to others in the past. The dom directory was done in preparation of improving the extension system by providing a live DOM interface to plugins. We've even had members of the SVG and XML committees review and endorse the approach.
The approach taken in the dom/ directory is totally wrong. It attempts to create yet another tree which is live-updated from the SP tree. The correct way to do this is to bind the actual SP objects to the DOM interfaces. Moreover, this work was nowhere near completion, since the essential part - how to present any kind of API to the extensions, so that they can directly modify the document rather than operating on its XML serialization - was never done.
Moreover, the DOM APIs defined in the SVG specification are very limited and do not provide any facilities to conduct geometric calculations. For example, they don't define any geometric primitives which are not elements.
Regards, Krzysztof
I added Krzysztof's list to Inkscape GSOC wiki page.
On Mon, 2014-02-24 at 23:51 -0800, Bryce Harrington wrote:
On Mon, Feb 24, 2014 at 11:14:41AM -0800, Josh Andler wrote:
Hey All,
We've been accepted again as a mentoring organization for Google's Summer of Code. This is the 10th year they've held it and our 10th year participating! If you're a potential mentor or student, please sign up at melange (1).
If you are interested in participating as a student please visit our page on Melange (2) to find links to our Ideas for summer projects on our wiki and our developer mailing list. As usual, please either introduce yourself on our developer mailing list or let us know what you're interested in working on this year.
Cheers, Josh
(1) http://google-melange.appspot.com/ (2) http://google-melange.appspot.com/gsoc/org2/google/gsoc2014/inkscape
Here's also a bunch of good ideas Krzysztof posted several weeks back. Some of these may be a little too ambitious to do in a summer so would need scoped down.
- Improve Icon Cache
Convert the icon cache (icon.cpp) to create the PNGs with a directory structure and index file matching the icon theme specification. Use this to get rid of customized classes InkAction, SPIcon, and so on.
- Remove dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.
- SAX parser
Convert the current document parser from DOM to SAX, so that it creates our XML tree right away, instead of creating the libxml2 DOM tree, creating our tree to match it, then freeing the libxml2 tree. This should improve performance and allow more robust fixes for some problems.
- Rewrite of Geom::PathVector and Geom::Path
Change PathVector to be a real object instead of a std::vector of Path, so that it can have useful methods, similar to curves. Move the copy-on-write idiom to the PathVector object, rather than using it in the Path. Investigate whether it is possible to store subpath data in a more compact way and make the Curve objects only convenience facades. Right now, if the path has only linear segments, every point is stored twice. Apply the following renames to match SVG terminology: Path -> Subpath PathVector -> Path
- Boolean operations and stroking
Add methods to PathVector objects: a) Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm. b) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation. c) stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
- Renderer improvements
This is a big task which has several sub-tasks: a) Unify the interactive and non-interactive renderers. (It would be desirable to have one codebase, but we need to investigate a little more whether this is practical.) b) Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL. c) OpenGL renderer - implement an OpenGL 3.x+ canvas which would render Beziers using this method: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html Investigate whether this generalizes to S-basis and circular arcs. Since the described method does not handle stroking, this work depends on 5. Also check how OpenGL path rendering is implemented in Qt, since apparently the performance there is very good. http://zrusin.blogspot.com/2011/09/nv-path-rendering.html
- Typed XML tree
Improve XML tree so that it can store some attributes in parsed, binary form. The main target of this are the data URIs used to embed images, which could be stored as binary data only. This work should be done after completing task 3 (SAX parser), as this will make it easier.
- Shape manipulators
The idea here is to rewrite shape tools in the same paradigm as the node tool. Instead of storing all information about the shape in knots which differ only by their callbacks, allow to store information in a higher-level manipulator object. This would enable things like dragging the side of a rectangle and consistent outlining / update preferences for all shapes.
- Improve the performance of layer visibility
Right now, toggling layer visibility causes massive changes in the display tree, because the entire toggled layer is invalidated at the XML level. This results in very bad performance for an action which should nearly instantaneous. Improve the control flow so that only the visibility of the object representing the layer is turned off, but the remainder of the display and object tree is leaved alone.
- Common build system for all platforms
Migrate the build system to Waf for all platforms. Alternatively, if there are important technical reasons why Waf is not suitable, port all necessary features to the CMake build system and remove Autotools.
- Remove SPCurve
SPCurve is a thin wrapper around Geom::PathVector which exists for historical reasons. Its functionality should be added to PathVector, and SPCurve should be purged.
- Use a different data structure for Inkscape::Selection
Inkscape::Selection currently uses GSList as its data structure. This is suboptimal, since a very common operation is checking whether some object is selected. Change Inkscape::Selection so that its underlying structure is a boost::multi_index container which implements the same semantics as Java's LinkedHashSet.
- Remove all use of GList and GSList
These GLib data structures are poorly designed (they are simple lists without sentinels, leading to blunders such as O(N) performance when appending to a doubly-linked list) and not type-safe. Replace all uses with standard C++ containers or suitable Boost containers.
- Box blur
Currently we always use a very accurate method to compute the Gaussian blur filter. Add an alternate method which approximates Gaussian blur using three stacked box blurs (simple averages). This is detailed in the SVG 1.1 SE specification.
- GTK3 on Windows
Rebuild the Windows devlibs so that they contain GTK3. Make the Windows port work with them, possibly sending the appropriate patches to the GTK maintainers.
- Migrate argument parsing to GOption and remove the dependency on popt
Write test cases for this bug, so that the patches can be accepted into GLib: https://bugzilla.gnome.org/show_bug.cgi?id=522131 If this proves hard, simply apply the patch to the devlibs. Once this is done, port argument parsing to GOption.
- Extension system improvements
Refactor the extension API. Clean up the kludgy class hierarchy, possibly using multiple inheritance. Use GInputStream and GOutputStream as parameters instead of file paths, so that things like the clipboard can have
- Robust ID handling
Currently ID clash resolution is implemented as a giant switch over object types, listing every possible dependency. Replace this with virtual methods on objects, which provide information on what each object refers to. Improve behavior when a dependency of an object is deleted, and when IDs are changed / deleted from the XML editor.
Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (9)
-
Bryce Harrington -
Johan Engelen -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Markus Engel -
Martin Owens -
Nathan Hurst -
Tavmjong Bah