Difference between revisions of "Google Summer of Code"

From Inkscape Wiki
Jump to navigation Jump to search
(35 intermediate revisions by 6 users not shown)
Line 12: Line 12:


* Google program information:
* Google program information:
** [https://www.google-melange.com/gsoc/homepage/google/gsoc2014 Home page].
** [https://summerofcode.withgoogle.com/ Home page].
** Summer of Code Application form. Applications open at 19:00 UTC on March 10th.
** Summer of Code Application form. Applications open at 19:00 UTC on March 14th.


* Inkscape-specific information:
* Inkscape-specific information:
Line 21: Line 21:
** [[SOC Selection Criteria]] - how we rate applications.
** [[SOC Selection Criteria]] - how we rate applications.


'''Student Applications for GSoC 2014 must be submitted to the GSoC site by 19:00 UTC on March 21st 2014.'''
'''Student Applications for GSoC 2016 must be submitted to the GSoC site by 19:00 UTC on March 25th 2016.'''


= The "two patches" rule =
= The "two patches" rule =
Line 48: Line 48:
Remember: ''we want you to succeed!''
Remember: ''we want you to succeed!''


= Suggested Ideas =
= Suggested Project Ideas =


Please note that your project proposal must be realistic: if you promise too much, we will most likely think you have not understood at all what it is about and will reject your proposal.
The following is a list of formal project suggestions, but do not feel limited to only these - some of our best contributions have been unique ideas that students had in mind from other sources!


See also [[Development Project Ideas]] and https://blueprints.launchpad.net/inkscape/


== Internal work & Performance improvements ==


* Improve startup time and initialization performance (i.e. improve font cache).
==P1. Better CSS Style Sheet Support==
* 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.
* 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.
* 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:
** Set operators (& | - ^), which perform the relevant boolean operation on the paths. Use the algorithm from CGAL or devise a new robust algorithm.
** stroke(double line_width, LineJoin join, LineCap cap, double miter_limit), which performs the stroke-to-path operation.
** stroke(double line_width, LineJoin join, LineCap cap, double miter_limit, std::vector<double> const &dasharray), which performs stroke-to-path with dashing.
* 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.
* 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.
* Continue C++ification (including more use of the gtkmm-framework as well as well as string classes (std::string and glib::ustring) in favor of C-strings).
* [https://blueprints.launchpad.net/inkscape/+spec/icc-for-cairo ICC Color Management for cairo outputs] - Would allow Inkscape to produce CMYK PDFs and PSs with Cairo. <!-- Isn't this more of a Cairo project? -->


== Rendering Improvements ==
Enhance Inkscape's support for CSS style sheets.


* 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.)
* Estimation of difficulty: Moderately hard
* Pluggable renderers - allow writing rendering backends which use something other than Cairo, e.g, OpenGL, Skia, Mozilla Azure or GEGL.
* Potential mentors: Tavmjong Bah
* 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 implementing boolean operations and stroking. 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
* Programming skills needed:  C++
* Prerequisites: Experience with CSS style sheets.


== Better SVG standard coverage ==
<u>Detailed Description</u>


* Full SVG viewbox support
Currently Inkscape support of CSS style sheets is limited to the reading and parsing of one internal style sheet. The styles are immediately stored in the style attribute for each object thus changes to the style sheet (awkwardly possible now through the XML editor) are not recognized. This project will:
* [[multipage | Multiple Page support]]
* Improve SVG compliance. [http://tavmjong.free.fr/INKSCAPE/W3C_SVG_1.1F2/harness/htmlInkscapeApproved/index.html Current status of W3C test suite compliance].


== SVG 2 and CSS3 ==
* Add to each object property a means to track the source of the property value.
* Create a dialog for editing internal style sheets. The dialog needs to:
** Support selectors based on object type, object id, and object class.
** Create selection sets based on the above selectors.
** Create and edit class names.


See: [[SVG2]].
A dialog similar to (and perhaps merged with) the trunk Selection Set dialog might be a good model to follow.


This includes providing suitable GUI and SVG 1.1 fallbacks.
Stretch goals include:


* Filling and Stroking
* Support external style sheets.
** [http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position Stroke position]
* Support multiple internal style sheets.
** [http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_dash_adjustment Stroke dash adjustment]
* Support CSS 3 selectors.
** [https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint Multiple fills]
* Support parsing of 'font-face'.
** [https://svgwg.org/svg2-draft/painting.html#PaintOrder Paint order] (Rendering alread implemented, needs GUI and fallback.)
** Marker color matching stroke.
** Vector Effects (non-destructive boolean-ops would be a good start)
** [http://www.w3.org/TR/css3-color/ CSS3 color support]
** [http://dev.w3.org/fxtf/compositing-1/ CSS3 blend modes]


* Paint servers
<u>Use Cases</u>
** [https://svgwg.org/svg2-draft/pservers.html#SolidColors Solid-color support] (Named colors, would deprecate the single-stop gradient approach we currently use)
** [https://svgwg.org/svg2-draft/pservers.html#MeshGradients Mesh gradient] (Basic implementation done, needs refinement and fallback.)
** [https://svgwg.org/svg2-draft/pservers.html#Hatches Hatched patterns]


* Text
* Support externally created SVGs.
** [https://svgwg.org/svg2-draft/text.html CSS based text flow]
* Producing better SVGs for the Web.
* Changing style on multiple objects at once (palettes).


* Misc
<u>Related Material</u>
** [http://www.w3.org/TR/css3-transforms/ CSS3 2d and 3d transforms]


* [https://www.w3.org/TR/CSS2/ CSS 2 Specification]
* [https://www.w3.org/TR/css-2015/ CSS 2015 Snapshot]


Note: Some of the above items are somewhat low hanging fruit and would need a few of them to make a good proposal, others alone are worthy of a full GSoC project.


== Improve Inkscape SVG for use on Web ==
==P2. Development Project Management System==


A proposal should fix most if not all of these problems:
Enhance Inkscape's web tools for managing development projects.


* Fix "plain" SVG to not remove <script> section, etc.
* Estimation of difficulty: Moderately hard
* Add option to set viewbox attribute to Document Properties.
* Potential mentors: Bryce Harrington
* Easily add/edit hyperlinks.
* Programming skills needed:  Python
* Better CSS support.
* Prerequisites:  Working knowledge of Django web application development
* Option to add title to SVG (searchability and accessibility).
* Remove XML prolog/DOCTYPE.
* Move sodipodi namespace items to Inkscape namespace.


== Live Path Effects related ==
<u>Detailed Description</u>


* [https://blueprints.launchpad.net/inkscape/+spec/lpe-blueprint More Live Path Effects] - There is a lengthy list of ideas to choose from here.
Design and implement tools to allow submitting and editing ideas for development projects.  Create various project listing views that display projects that need further editing, lists of projects meeting various criteria (e.g. janitorial, new features, programming language, etc.), assigned projects, completed projects, and so forth.


== Tools and shapes related ==
This work would be part of a larger, ongoing effort to unify Inkscape's various collections of task ideas into a single system, to make them easier for potential contributors to review and select from.  Some of this project has already been implemented, so you would be focusing on enhancing its user interfaces to make it more powerful and more broadly usable.


* 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.
<u>Use Cases</u>
* [https://blueprints.launchpad.net/inkscape/+spec/transformation-anchors Transformation Anchors]
* "Janitorial" tasks suitable for new developers looking for easy ways to get involved in Inkscape development
* Extend the Symbols dialog to include generic objects.
* Google Summer of Code Project Ideas (this page!!)
* [https://blueprints.launchpad.net/inkscape/+spec/inkscape-connectors Connector tool improvements] - Expose new libavoid functionality: orthogonal routing, connector ports, curved connectors. (Mentor: Michael Wybrow)
* Funded development work, with funds supplied by various fundraisers
* [https://blueprints.launchpad.net/inkscape/+spec/fillet-tool Fillet/Chamfer tool]
* User-supplied requests for feature enhancements


<!-- All of these seem to be low priority for GSoC
<u>Related Material</u>
* Current collections of tasks that we want to eventually migrate into this system:
** http://wiki.inkscape.org/wiki/index.php/Janitorial_tasks
** https://blueprints.launchpad.net/inkscape/
* [https://inkscape.org/en/support-us/funded-development/ High level specification for the system]
* [[FundedProjectSystemDevelopment]] related tasks


== Import/export projects ==


* Importing of 3D scene files in 16 file formats using [http://assimp.sourceforge.net/ Open Asset Import Library]
==P3. Slice toolbar items==
* [https://blueprints.launchpad.net/inkscape/+spec/xar-to-svg-converter xar-to-svg converter] - Converter for Xara Xtreme to Inkscape
[[File:Cuttool.png|200px|thumb|right|Example of result of the cut/eraser tool]]
* [https://blueprints.launchpad.net/inkscape/+spec/kml-svg-translation KML SVG translation] - For use of Inkscape with Google Earth or Maps
* Estimation of difficulty: Moderately hard
* Potential mentors: Jabier Arraiza (Spanish, some English)
* Programming skills needed: C++


<u>Detailed Description</u>
The goal is a toolbar item, called "slice" to slice items in a easy way.
We check to convert strokes to path previously to cut, to avoid continuing with stroke thought cut-out item fills.<br />
Maybe positioned in the path menu after bool operations, the selected items are sliced from topmost path, converting strokes to paths, duplicating fills and maybe apply to groups (there is some work in groups boolops from Martin Owens). <br />
A lot of helper code is done yet in flatten branch (Alexander Brock lp:~inkscape+alexander/inkscape/flatten).<br />
There are new Boolean operations, implemented but not used in trunk. We need to switch the division and flatten branch methods from Livarot to these new operations.<br />
Another feature interesting is a second toolbar item "slice from guides" to get the guides over the selected item and use it as cut-out.<br />


== Generic ideas ==
<u>Use Cases</u>
* Better item slicing.


* Font editing and creation features, e.g. [https://blueprints.launchpad.net/inkscape/+spec/designing-svg-fonts-using-styles designing SVG fonts using styles]
==P4. SVG 2 Text Support==
* [https://blueprints.launchpad.net/inkscape/+spec/kidscape-project kidscape] - Condensed version of Inkscape aimed at young kids and small form factor devices
* [https://blueprints.launchpad.net/inkscape/+spec/cutter-control Cutter control] - Enable Inkscape's use with vinyl cutters.
-->


Please do not feel limited to the above ideas - some of our best contributions have been unique ideas that students had in mind from other sources!
* Estimation of difficulty: Hard
* Potential mentors: Tavmjong Bah
* Programming skills needed: C++
* Prerequisites: Familiarity with text layout. Knowledge of CSS.


For more ideas, please see https://blueprints.launchpad.net/inkscape/
<u>Detailed Description</u>
 
Inkscape currently has a non-compliant flowed text feature (based on SVG 1.2 which was never adopted) that needs to be made compatible with both SVG2 and SVG 1.1. This project is to re-implement the flowed text feature within Inkscape to be SVG2 compliant and to have a proper SVG 1.1 fallback. In addition to the flowed text itself as it exists within Inkscape, SVG2 adds new formatting features including shape-margin and shape-padding, shape-inside and shape-outside, exclusions, additional white-space control settings, pre-wrap, pre-line, etc.
 
<u>Use Cases</u>
* Proper text flow into rectangles and other shapes.
 
<u>Related Material</u>
* [https://svgwg.org/svg2-draft/text.html Current draft of SVG 2 text specification.]
 
==P5. Better data structure for selections==
 
* Estimation of difficulty: Medium
* Potential mentors: Krzysztof Kosiński (Polish, English)
* Programming skills needed: C++
* Prerequisites: Familiarity with STL and/or Boost, knowledge of basic data structures and their performance properties, some knowledge of glib a plus.
 
<u>Detailed Description</u>
 
Many useful functions in Inkscape, such as grouping, Boolean operations, etc., work on a selection. However, there is only one selection object per window, and its state is shown in the user interface. It would be useful to have an object type that represents the same concept, but not tied to the user interface.
 
This project would involve implementing an <code>Inkscape::ObjectSet</code> object that would serve as a base for <code>Inkscape::Selection</code>. The internal data structure should support fast lookup (checking whether a given object belongs to the set) and preserve the order of insertion (so that we can still determine which object was selected first or last). Internally, <code>ObjectSet</code> can be based on a Boost multi-index container with a list index and a hash index.
 
<u>Related Material</u>
* [http://www.boost.org/doc/libs/1_60_0/libs/multi_index/doc/index.html Boost Multi-Index Containers Documentation]


= Successful SOC Projects from Previous Years =
= Successful SOC Projects from Previous Years =
Line 196: Line 200:
** A test suite
** A test suite
* 2009
* 2009
** [[GSoC 2009 Node Tool Rewrite|Node tool rewrite]]
** [[GSoC2009 Node Tool Rewrite|Node tool rewrite]]
** D-Bus scripting API
** D-Bus scripting API
** Connector tool improvements
** Connector tool improvements
Line 217: Line 221:
** New From Templates Dialog
** New From Templates Dialog
** New Raster to Vector Algorithm
** New Raster to Vector Algorithm
* 2014
** Better Support for SVG Paints
** Robust Boolean and Stroking Operations for 2Geom
* 2016
** [[GSoC 2016 Better data structure for selections|Better data structure for selections]]
[[Category:Developer Documentation]]
[[Category:Developer Documentation]]

Revision as of 09:41, 23 August 2016

Welcome to Inkscape!

For quite a few years Inkscape has been successfully participating in Google Summer of Code.

GSoC is a program where Google funds the development of specific features in open source software by university students. You don't need to be a Computer Science student to apply. Features to be developed are picked by Inkscape administrators from the pool of proposals submitted by students.

We've mentored about half a dozen students a year since GSoC started. Many students enjoyed their work and continue to be involved; perhaps your mentor will be a past GSoC student! We have a high rate of acceptance of student code into the core codebase. Indeed, GSoC projects have been a key source of some of Inkscape's best features in the past several releases.

If you are interested in joining us this summer, it is time to get your proposal ready. You can choose a proposal from our list of suggestions or come up with one of your own. In either either case, you must give us a detailed outline of what you plan to do. It is highly recommended that you discuss your idea as early as possible with Inkscape developers. They not only can give you guidance as you flesh out your proposal but ultimately you must convince them that you can do the work planned in the time allotted.

Student Applications

  • Google program information:
    • Home page.
    • Summer of Code Application form. Applications open at 19:00 UTC on March 14th.

Student Applications for GSoC 2016 must be submitted to the GSoC site by 19:00 UTC on March 25th 2016.

The "two patches" rule

We require two patches from each potential GSoC student, before accepting the student for GSoC participation (it is the same requirement as for obtaining rights to commit changes to the Bazaar code repository). The reason for this requirement is that you can show us that you have succeeded in building Inkscape on your PC, and that you have understood a little piece of Inkscape's code and are able to improve it. Inkscape is a large project, and you really should not try to understand all the code. Many (all?) developers know only parts of the program code! You can join our jabber/IRC channel and ask developers for help.

Suggested "easy" bug fixes or improvements

To get you started on Inkscape development, you can find (probably) easy-to-fix bugs or small improvements that require very little knowledge of the whole program by searching our bug-tracker for bugs tagged with 'easy-fix'.

Performance Evaluation

GSoC has two formal evaluation points, at the mid-term and at the end. These evaluations determine if you receive the stipend from Google. In order to receive a pass for the evaluations you will need to show adequate progress toward your project's goals.

To help you meet your goals and so that your mentor can better evaluate your progress you need to:

  • Have frequent, public discussions of your progress. (Don't rely on just your mentor for advice.)
  • Have a public Inkscape branch for your code to which you commit regularly.
  • Give weekly status reports.

For the final pass, you will normally be required to merge your code into Inkscape trunk.

Remember: we want you to succeed!

Suggested Project Ideas

The following is a list of formal project suggestions, but do not feel limited to only these - some of our best contributions have been unique ideas that students had in mind from other sources!

See also Development Project Ideas and https://blueprints.launchpad.net/inkscape/


P1. Better CSS Style Sheet Support

Enhance Inkscape's support for CSS style sheets.

  • Estimation of difficulty: Moderately hard
  • Potential mentors: Tavmjong Bah
  • Programming skills needed: C++
  • Prerequisites: Experience with CSS style sheets.

Detailed Description

Currently Inkscape support of CSS style sheets is limited to the reading and parsing of one internal style sheet. The styles are immediately stored in the style attribute for each object thus changes to the style sheet (awkwardly possible now through the XML editor) are not recognized. This project will:

  • Add to each object property a means to track the source of the property value.
  • Create a dialog for editing internal style sheets. The dialog needs to:
    • Support selectors based on object type, object id, and object class.
    • Create selection sets based on the above selectors.
    • Create and edit class names.

A dialog similar to (and perhaps merged with) the trunk Selection Set dialog might be a good model to follow.

Stretch goals include:

  • Support external style sheets.
  • Support multiple internal style sheets.
  • Support CSS 3 selectors.
  • Support parsing of 'font-face'.

Use Cases

  • Support externally created SVGs.
  • Producing better SVGs for the Web.
  • Changing style on multiple objects at once (palettes).

Related Material


P2. Development Project Management System

Enhance Inkscape's web tools for managing development projects.

  • Estimation of difficulty: Moderately hard
  • Potential mentors: Bryce Harrington
  • Programming skills needed: Python
  • Prerequisites: Working knowledge of Django web application development

Detailed Description

Design and implement tools to allow submitting and editing ideas for development projects. Create various project listing views that display projects that need further editing, lists of projects meeting various criteria (e.g. janitorial, new features, programming language, etc.), assigned projects, completed projects, and so forth.

This work would be part of a larger, ongoing effort to unify Inkscape's various collections of task ideas into a single system, to make them easier for potential contributors to review and select from. Some of this project has already been implemented, so you would be focusing on enhancing its user interfaces to make it more powerful and more broadly usable.

Use Cases

  • "Janitorial" tasks suitable for new developers looking for easy ways to get involved in Inkscape development
  • Google Summer of Code Project Ideas (this page!!)
  • Funded development work, with funds supplied by various fundraisers
  • User-supplied requests for feature enhancements

Related Material


P3. Slice toolbar items

Example of result of the cut/eraser tool
  • Estimation of difficulty: Moderately hard
  • Potential mentors: Jabier Arraiza (Spanish, some English)
  • Programming skills needed: C++

Detailed Description The goal is a toolbar item, called "slice" to slice items in a easy way. We check to convert strokes to path previously to cut, to avoid continuing with stroke thought cut-out item fills.
Maybe positioned in the path menu after bool operations, the selected items are sliced from topmost path, converting strokes to paths, duplicating fills and maybe apply to groups (there is some work in groups boolops from Martin Owens).
A lot of helper code is done yet in flatten branch (Alexander Brock lp:~inkscape+alexander/inkscape/flatten).
There are new Boolean operations, implemented but not used in trunk. We need to switch the division and flatten branch methods from Livarot to these new operations.
Another feature interesting is a second toolbar item "slice from guides" to get the guides over the selected item and use it as cut-out.

Use Cases

  • Better item slicing.

P4. SVG 2 Text Support

  • Estimation of difficulty: Hard
  • Potential mentors: Tavmjong Bah
  • Programming skills needed: C++
  • Prerequisites: Familiarity with text layout. Knowledge of CSS.

Detailed Description

Inkscape currently has a non-compliant flowed text feature (based on SVG 1.2 which was never adopted) that needs to be made compatible with both SVG2 and SVG 1.1. This project is to re-implement the flowed text feature within Inkscape to be SVG2 compliant and to have a proper SVG 1.1 fallback. In addition to the flowed text itself as it exists within Inkscape, SVG2 adds new formatting features including shape-margin and shape-padding, shape-inside and shape-outside, exclusions, additional white-space control settings, pre-wrap, pre-line, etc.

Use Cases

  • Proper text flow into rectangles and other shapes.

Related Material

P5. Better data structure for selections

  • Estimation of difficulty: Medium
  • Potential mentors: Krzysztof Kosiński (Polish, English)
  • Programming skills needed: C++
  • Prerequisites: Familiarity with STL and/or Boost, knowledge of basic data structures and their performance properties, some knowledge of glib a plus.

Detailed Description

Many useful functions in Inkscape, such as grouping, Boolean operations, etc., work on a selection. However, there is only one selection object per window, and its state is shown in the user interface. It would be useful to have an object type that represents the same concept, but not tied to the user interface.

This project would involve implementing an Inkscape::ObjectSet object that would serve as a base for Inkscape::Selection. The internal data structure should support fast lookup (checking whether a given object belongs to the set) and preserve the order of insertion (so that we can still determine which object was selected first or last). Internally, ObjectSet can be based on a Boost multi-index container with a list index and a hash index.

Related Material

Successful SOC Projects from Previous Years

  • 2005
  • 2006
    • Support for SVG Filters
    • Filter Effects
    • PDF export
    • Inkboard Protocol Spec / Lib Conversion
  • 2007
    • Text Style Improvements
    • PDF import
    • Live Path Effects
    • 3D Box Tool
    • UI for SVG Filter Effects
    • Raster Functionality
    • Importing from, and Exporting to, a remote ccHost instance
  • 2008
    • SVG Fonts support
    • 2Geom refactoring project - port most geometry code to 2Geom
    • lib2geom: interactive applications showing off the power of lib2geom
    • Tech drawing abilities
    • A test suite
  • 2009
  • 2010
    • Cairo-based rendering
    • C++ification of SP Layer
  • 2011
    • Rendering caching
    • Javascript support improvements
    • CSS support improvements
  • 2012
  • 2013
    • Recolor Tool
    • Improved Units Support
    • Electronics CAD Support
    • New From Templates Dialog
    • New Raster to Vector Algorithm
  • 2014
    • Better Support for SVG Paints
    • Robust Boolean and Stroking Operations for 2Geom
  • 2016
Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=Google_Summer_of_Code&oldid=101776"