This page lists proposed projects for possible funding requests. The original list is from Krzysztof Kosiński. Consider it a permanent work-in-progress "brainstorm" list and feel free to add your own comments and project proposals. None of these are "official" and have not been thoroughly reviewed/debated and so may or may not fit with actual development plans.
- 1 Infrastructure
- 2 Interface
- 3 SVG Support
- 4 Paths
- 5 Print
- 6 Other
- 7 Finished Projects
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.
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.
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.
It should be possible to change ID and have Inkscape update all references. It should also not be automatically created for all objects. Tav
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. Partially Done
Clean up all unnecessary castings in C++ classes. Remove unnecessary use of "this". Etc.
In depth code reviews of submitted patches. This is done by some other projects with great success. It speeds up getting patches committed which encourages contributions. It can also be a good learning experience.
GTK 3 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.
this is already being worked on by Jazzy Nico: https://code.launchpad.net/~inkscape.dev/inkscape-devlibs/devlibs-gtk3
Provide actions which are actually relevant in the context menu, depending on the context of the selection. Examples of such actions include: release mask, release clipping path, put text on path, embed / extract image, unflow text, and so on.
Page size editing on the canvas
Provide a way to edit the page size directly on the canvas, using a manipulator similar to a rectangle.
On-canvas tool controls
More tool controls could be available on-canvas right by the object being edited. An example of this would be having some of the text tool controls available right by where text editing is happening akin to what GIMP provides.
Numeric input on the canvas
Right-clicking on nodes should bring up a numeric entry box which would allow you to specify its position numericaly. This could allow us to phase out some of the controls on the top bar. For dynamic offsets, the numeric entry would simply be the width of the offset
Unify document and desktop coordinates
Change the desktop coordinates to match document coordinates. Make it so that document coordinates are specified in the coordinate system of the toplevel SVG element, so that it is possible to emulate other coordinate systems using a suitable transform attribute or viewBox.
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.
We have a solid plan on how to do this without special svg 2.0 spec and it's technically pretty simple, involving layers and the way we currently specify layer type. It's a project which would attract a lot of attention, even if at first the support didn't include saving the pages to pdf or other such documents.
Move the existing flowed text XML representation into an svg:switch and provide an alternative fallback representation with SVG 1.1 text objects only.
This should be done via SVG 2 CSS text wrapping which provides a simple SVG 1.1 fallback mechanism.
Refactor live path effects so that their XML representation matches that of SVG 2.0 vector effects. Put them in switches, so that the output is not limited to a single path. Integrate them better with core Inkscape. For instance, instead of four actions: inset, outset, dynamic offset, linked offset, there should be only one: offset. Using it on a normal path would create a dynamic offset, while using it on a clone would create a linked offset. The same principle would apply to vector effects: creating them on a normal path would move the path to defs and replace it with the vector effect, while creating them on clones would delete the clone and create a reference to the original path.
Create the document and rendering tree for linked SVG images. Use Inkscape's renderer instead of relying on the librsvg loader to avoid inconsistencies. Allow importing the linked image as a group via the context menu.
Mesh gradients, hatches, etc. See SVG2 page. Tav
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.
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.
Fill out arcs functionality
For accurate path Boolean operations with elliptical arcs, allow arcs in PathVectors and support Boolean operations between arcs and between elliptical arcs and S-Basis curves. Tav
Analyze what users require for CMYK and other aspects of color management, including a review of what other software does, and what can currently be done with Inkscape. Examine off the shelf code that could be used (e.g. libcms). Define what needs implemented in Inkscape's dependencies (e.g. libcairo) vs. what can or must be done in Inkscape itself. Outline project(s) to implement the needed changes. See Color_management.
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
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
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.
Improve Inkscape's connectors, following the proposed SVG connectors spec. Tav
Support animation in Inkscape. Should implement the model from the Web Animations specification so that both SMIL and CSS animations are supported. Inkscape Community/Tav
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
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.
- "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
- Current collections of tasks that we want to eventually migrate into this system:
- High level specification for the system
- FundedProjectSystemDevelopment related tasks
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. </style>
Common build system for all platforms
Migrate and port all necessary features to the CMake build system and remove Autotools.
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 dom/ directory
This directory contains strange code which is barely used. The only class which is actually used is the URI class.