Difference between revisions of "Roadmap update proposal"
(Created page with '(WORK IN PROGRESS) This is a proposal to update the roadmap at Roadmap. The current one is not very useful, because it has become a wishlist of miscellaneous things that do ...') |
|||
(One intermediate revision by one other user not shown) | |||
Line 4: | Line 4: | ||
This list is a start for discussion and is by no means official. | This list is a start for discussion and is by no means official. | ||
Note: after a quick review, there appear to be major issues with about a third of these. So please keep in mind the earlier caveat that this is just the initial start of a discussion. [[User:JonCruz|JonCruz]] | |||
==Short term goals (should be done for next release)== | ==Short term goals (should be done for next release)== | ||
Line 42: | Line 44: | ||
|2geom side almost ready, Inkscape side not started | |2geom side almost ready, Inkscape side not started | ||
|display/curve.cpp | |display/curve.cpp | ||
|- | |||
|Signal review | |||
|Remove the emitting object parameter from all signals, and convert the code that needs a reference or pointer to the emitting object to <tt>sigc::bind</tt>. | |||
See [[Using libsigc++ signals]] for an overview of signals. | |||
|not started | |||
|For example, selection.cpp and desktop.cpp | |||
|- | |- | ||
|Windows Metafile support | |Windows Metafile support |
Latest revision as of 06:48, 14 August 2009
(WORK IN PROGRESS)
This is a proposal to update the roadmap at Roadmap. The current one is not very useful, because it has become a wishlist of miscellaneous things that do not have any planning or design behind them. Moreover, planning for a specific release doesn't look like a good idea, because frequently no one steps up to implement a given feature. Therefore relaxing the roadmap into three broad categories: short term, medium term and long term goals - might be a good idea.
This list is a start for discussion and is by no means official.
Note: after a quick review, there appear to be major issues with about a third of these. So please keep in mind the earlier caveat that this is just the initial start of a discussion. JonCruz
Short term goals (should be done for next release)
Goal | Description | Status, implementors | Relevant files |
---|---|---|---|
Kill livarot | Remove the livarot library in favor of 2geom; extend 2geom where necessary | Some boolops and offset code ready in 2geom, though not yet used in Inkscape | splivarot.cpp |
Color storage in preferences | Preferences should store color values as human-readable hex rather than bogus integer numbers | Not started | preferences.cpp |
Document settings framework | A more robust and easy to use way to store per-document settings. On the XML side, it should store everything in an <inkscape:document-settings> element with sub-elements for page settings, snap settings, etc. On the application side, it should expose an API similar to Inkscape::Preferences. Some implementation details could be shared. | Not started; Per-document settings are stored in the legacy SPNamedView class | sp-namedview.cpp, preferences.cpp |
Better export dialog | The export dialog should allow exporting to any format, including vector formats and all bitmap formats supported by GdkPixbuf. The Save dialog should be reduced to only include roundtrip-capable formats (e.g. saving in this format and then loading the document back should result in the same SVG representation). | Not started |
Medium term goals (2-3 releases)
Goal | Description | Status | Relevant files |
---|---|---|---|
Kill SPCurve | Remove SPCurve in favor of Geom::PathVector; provide all necessary operations in 2geom | 2geom side almost ready, Inkscape side not started | display/curve.cpp |
Signal review | Remove the emitting object parameter from all signals, and convert the code that needs a reference or pointer to the emitting object to sigc::bind.
See Using libsigc++ signals for an overview of signals. |
not started | For example, selection.cpp and desktop.cpp |
Windows Metafile support | Support saving in WMF and EMF on all platforms; use this code to support directly copying and pasting between Word/OpenOffice and Inkscape | System-wide clipboard done; EMF save support is Windows-only | ui/clipboard.cpp, extension/internal/emf-win32-inout.cpp |
Cairo-based renderer | Replace as much of libnr with Cairo as reasonably possible | Outline mode already uses Cairo | display/ directory |
Use Gtk::Action | Attempt to replace Verbs with Gtk::Actions, using one derived class per verb, preferably along with a system of dynamically registering new actions from extensions and tools; Use Gtk::UIManager to build all menus and toolbars; remove SPAction, InkAction, etc. | Actions are used internally for example in widgets/toolbox.cpp, but overall this area remains a mess | verbs.cpp, interface.cpp, widgets/toolbox.cpp |
Tools refactoring | Port event contexts to C++ and rename to "tools"; augment with clipboard handlers and UI hooks to get rid of the toolbox.cpp monstrosity | Initial design of the internal architecture as part of GSoC2009 node tool rewrite; External tool API not started | *-context.cpp, widgets/select-toolbar.cpp, widgets/toolbox.cpp |
Long term goals (unknown)
Goal | Description | Status | Relevant files |
---|---|---|---|
Better memory management | Remove the Boehm garbage collector; use smart pointers and clear ownership semantics (like Boost pointer containers) where appropriate; create tutorials on running Inkscape under Valgrind to catch memory leaks | Not started | gc-*.cpp |
Better documentation | Document all important areas of Inkscape codebase: object tree, undo stack, XML tree, renderer, custom widgets, etc. Write developer tutorials on working with them. | Reasonably good documentation for the XML tree and the preferences subsystem, but most areas undocumented | all |
Full SVG 1.1 support | Provide support for all features of the SVG 1.1 standard | ? | all |
Animation support | Create and edit interactive SVG animations using SMIL or JavaScript | Not started | ? |
Inkcore | Separate reusable UI, XML, object tree, and renderer components into libraries reusable by other applications | Currently there are lots of interdependencies and nothing can be separated | ? |