Difference between revisions of "Roadmap"

From Inkscape Wiki
Jump to navigation Jump to search
(Revert spamming)
 
(→‎2Geom 1.0: Mark tasks as done.)
(191 intermediate revisions by 32 users not shown)
Line 1: Line 1:
== Problem ==
This is a working document showing specific near-term tasks needed for achieving the numbered milestones. It is '''not a wishlist''' of features to be included in future releases. Because people often work on whatever they feel like, only the current and current+1 releases should be taken seriously.  Beyond that is mainly conjectural.


Bryce has pointed out the #1 feature need for Inkscape right now is strong support for Adobe Portable Document Format (PDF) and Postscript (PS) in his  [http://sourceforge.net/mailarchive/forum.php?forum_id=36054&max_rows=25&style=flat&viewmonth=200511&viewday=30 2005.11.30 email] to the Inkscape mailing lists.
''See [[OldRoadmap]] for milestones that have already been achieved.''
This ConsensusPoll exists to enable the community to efficiently create and commit to a plan of action to resolve this issue.


== Contract ==
=== Inkscape 0.92 ~ Infrastructure Focus ===
* (DONE) <s>Set up autogeneration of Inkscape source code documentation ([http://wiki.inkscape.org/wiki/index.php/Doxygen_documentation Doxygen not available online according to old wiki page] but [http://fossies.org/dox/inkscape-0.91pre2/ available here (fossies.org)])</s> (http://jenkins.inkscape.org/job/Inkscape_trunk_doxygen/doxygen/)
** (DONE) <s>Put it publicly somewhere on the inkscape domain for "official" access.</s> (http://jenkins.inkscape.org/job/Inkscape_trunk_doxygen/doxygen/)
* (DONE) <s>Build system: migrate away from Autotools (See [[Build system improvements]])</s>
** (DONE) <s>Decide between CMake and Waf</s>
*** (DONE) <s>Alex will be doing a "neutral party" review of the two</s>  Decision to go with cmake for now.
** (DONE) <s>Get decided system working</s>
*** See [[CMake_Tasks]]
** (DONE) <s>Switch release tools to use new build system</s>  Documented for now; will wait on mechanizing it until after switch to git.
** (DONE) <s>Switch packaging tools to use new build system</s>
** (DONE) <s>Retain Autotools support one final release (legacy support)</s>, then drop next release.
* (DONE) <s>Make the Windows uninstaller work (reevaluate this, we now have msi installer for win32 and Win64)</s>


* >= 20 inkscape enthusiasts
=== 2Geom 1.0 ===
* >= 4 developers with commit access
* 2geom maintenance
* >= 95% yes
** (DONE) <s>Stop embedding 2Geom in Inkscape's codebase; handle it as a regular dependency</s> (https://gitlab.com/inkscape/inkscape/-/merge_requests/2109)
* all conditions in plan are met
** (DONE) <s>Move project to gitlab, from https://launchpad.net/lib2geom, http://lib2geom.sourceforge.net/, and https://github.com/inkscape/lib2geom [kk]</s> (https://gitlab.com/inkscape/lib2geom)
* 72 hour GO timer
** Possibly start doing lib2geom releases in conjunction with Inkscape's releases? [bryce]
* 80% cloture
** Add to PPAs and other CI / autobuilds we already use for Inkscape [alex + bryce]


ContractExplanation
=== Inkscape 1.0alpha ~ Maintenance and Optimization Focus ===
* (DONE) <s>Migration to Git</s>
* (DONE) <s>Migration to GitLab</s>
* (DONE) <s>Decide which Unit testing framework to use ([http://inkscape.13.x6.nabble.com/Unit-testing-td4967386.html Discussion July 2013 didn't get much traction])</s>
** Hackfest consensus is Google test.
* (DONE) <s>Set up continuous builds (e.g. Travis CI / Appveyor or gitlab)</s>
* (DONE) <s>Make C++11 compiler a hard requirement</s>
* (DONE) <s>Drop Autotools support (See [[Build system improvements]])</s>
* (DONE) <s>Migrate potrace to be an external dependency</s> Done for 0.92
* (DONE) <s>Gtk3/UI revamp</s> Down to bug fixing and follow-on work


Because this contract defines what it means to participate in this poll it will never be changedIf it turns out to be inadequate, this poll must be canceled and a new poll with a new contract must be drafted.
* Split out less well maintained extensions to an 'extras' package
** Add a test suite that runs each extension against a collection of test documents
** Possibly start doing inkscape-extras releases in conjunction with Inkscape's releases?
** If we don't achieve this by this release, push it to 1.1 or later
* Split tutorials and other content from the main executable, to enable them to be updated independently of our main release process
** Need to investigate where we stand with this, and re-evaluate more precisely what we want to do this release
* Prepatory work for expanded testing
** Document how to do the tests
** Create or identify a good model test case
** Implement example unit tests for:  SP objects, verbs, cmdline options, live effects, UI dialogs, UI widgets/tools, UI view, etc.
** Start collecting regression svg files in a testing repository somewhere
* Thorough testing of document recovery after crashMake this more robust.
** Need to better define what we want to test
** How should the crash be triggered?
** What should the document be?
** Need to be careful about what cases we actually want to consider
* Improved performance
** with an empty start
** when starting up with an existing file
** peppering printfs in the startup logic shows that some routines that should get called one time only, actually get called multiple times
** need to investigate if there is existing instrumentation tools that could be used to identify recursion or other causes of slowness during startup
* Improved mailing list archive
** Move existing archive to inkscape.org or add an archive mirror at inkscape.org ("official" inkscape information is spread out wide between different domains), this would be an improvement.
** Consider also bringing lib2geom mailing lists?
** inkscape: We need postmaster@inkscape.org and abuse@inkscape.org set up.  Maybe as part of a mailing list refresh?
* Set up effort to package selected branches and organize community testing around them
** Use this initially for changes planned for landing in 1.0
** Once we're feature-frozen for 1.0, use this mechanism for wider testing of new feature work
* Gtk+ 3 migration: Goal is a clean, deprecation-free build
** Stop using GtkActions.  Migrate toolbars to use plain widgets, and GAction
** Turn Inkscape into a proper Gtk::Application. Stop using Gtk::Main
** GtkMM/C++ify and clean up toolbar code
** Remove unused GtkAction-based widgets


== Yes-No Poll ==
=== Inkscape 1.0beta ~ Test Case and Documentation Writing Focus ===
* Write unit test cases
** Core functions
* Better translations - keep track of % translations for all languages.  Drive to 95% on all major languages.
* Cleanup website and wiki
** Move pages of value to users from wiki to the main website
** Trim down amount of legacy material presented in the wiki
* Coder stories
** different stories about how to do common development tasks, like hooking in a new widget or adding support of a new SVG tag
** have people sketch in what they know, then pass around for critique to optimize the description
** where to store the documentation?  Where would someone look?


Participation in this poll is open to anyone who wants to participate.
=== Inkscape 1.0 ===
* Strict bugfix focus, with all development targeted to feature branches
* This will be a long term stable release series


Voting yes in this poll means that you believe the community created plan is ready for implementation, and that you will do your part to support its execution.  Voting no in this poll means that you have outstanding concerns about the community created plan.  You can change your vote at any time.  All votes are transparent so that those voting yes can listen to the concerns of those voting no.
-----------------------------------
'''Following is a WIP draft of the post-1.0 release goals; this is not yet finalized, and should not be taken as official yet'''
-----------------------------------


No ... BrandonCsSanders    - Success needs to be defined (e.g., if all 20 test cases are passed ...)
=== Inkscape 1.1 ~ New Features ===
No ... BryceHarrington    - I will pledge $50 once someone defines how we do pledges :-)
* Land feature branches held for post-1.0
No ... AlexandreProkoudine - There is no plan yet
* SVG Flowed Text
  No ... ColinMarquardt      - There is no plan yet
** Fix flowtext
No ... EricWilhelm        - The plan needs salt
** Implement SVG 2 flowed text which has a natural SVG 1.1 fallback.
No ... MenTaLguY          - This isn't much of a plan...
** Ex. https://dl.dropboxusercontent.com/u/65084033/irc/ask-smart-questions.svg
No ... JonCruz            - Plan? Not quite yet
* Externalize some (easy) dependencies for better modularization
No ... JonPhillips        - no plan...
** Break libdepixelize out to its own library
No ... NicuBuculei        - so far the plan is weak
** Break libnrtype out to its own library
No ... RalfWStephan        - isolated thoughts don't make a plan, pledge 5% of SoC money amount used for it
** Break libuemf out to its own library
No ... AndyFitzsimon      - I will also pledge $50 once someone defines how we do pledges.
** Switch to using libcroco as a regular dependency (not embedded in our codebase).
No ... TuukkaPasanen      - There isn't good plan yet.
*** Contact maintainer to see if still actively maintaining, and if can roll a new release for us
No ... EricJonas          - There is no plan
*** Else, consider adopting maintenance of the library under the Inkscape project umbrella
*** Or consider replacement with libcss or other CSS parser.
*** See http://inkscape.13.x6.nabble.com/Should-inkscape-take-over-libcroco-td2784457.html
** Switch to using Adaptagrams (libvpsc, libcola & libavoid) as a regular dependency
*** Contact maintainer to see if still actively maintaining, and if can roll a new release for us
*** Else, consider adopting maintenance of the library under the Inkscape project umbrella
*** See https://bugs.launchpad.net/inkscape/+bug/1353833
* Complete conversion to GTK 3
** Drop use of libgdl in place of GtkNotebook
** Be smarter about toolbar layout so we never have invisible (but necessary) buttons off the screen.
** Rework panels so that they resize consistently and display contents better. Consider moving back to dialogs in some cases or moving more functionality to the canvas.
* Begin development of new plugin / extension system(s)
** C++ API with Python bindings
** Review the D-Bus scripting API GSoC work from 0.48 timeframe
** Easy to create
** Powerful enough to do LPEs, filters, etc.
** Probably need several different APIs for different levels in the codebase, such as atop the object model, one for canvas stuff, one atop the UI, etc.
*** For object layer will require better division from UI, so it doesn't require a selection for items to operate on
** Include a debug print of the loaded extensions/plugins/etc.
** Establish an Extensions Center for community-collaborative sharing/reviewing/maintaining extensions
*** Core extensions are shipped with Inkscape
*** User review ranking
*** Developer review ranking
*** Auto-QC ranking (mechanical testing, and checking for docs, test cases, etc.)
** Search the Extensions Center and install from within Inkscape
* Switch to using Poppler's API rather than using internals (the current situation causes regular breakage with new releases of Poppler)
* [[GtkMMification]]
* Improved performance
** Working with large files
** Working with files with lots of filters
* Consider setting up workflow (passing tests, test coverage, code review) for getting code into trunk.
** Improve new contributor experience for getting patch reviews
** Switch patch review software from launchpad to something like mailing list + patchwork, or phabricator
* make msi Windows install multilingual
* Implement application-scope actions and "remixable" user interfaces:
** Replace "Verbs" with application-scope Gio::Action definitions.
** Define user-interface using Gtk::Builder XML files.
** Provide command-line "headless" access to application actions.
** Provide documentation for all actions, and tutorial for GUI customization


(If you are voting no because the plan is incomplete, please describe what you'd like to see added or changed.)
=== Inkscape 1.2 ~ Refactoring ===
* Split backend / GUI frontend
* Flip y-coordinate to match SVG.
** Introduce a backwards compatibility mechanism that will allow us to modify the XML representation of editing info. This is needed to bring the desktop coordinate system in line with SVG due to guideline and 3D box problems (they save desktop coordinates in the XML). This can be done either at the SP tree level or by moving to a SAX-based parser which updates the editing information as the document is parsed.


== Pledges ==


$50 ... BryceHarrington  - I will pledge $50 once someone defines how we do pledges :-)
[[Category:Developer Documentation]]
$50 ... AndyFitzsimon    - I will also pledge $50 once someone defines how we do pledges.
??? ... RalfWStephan    - pledge 5% of SoC money amount used for it (how much is this?)
$50 ... BrandonCsSanders - once the plan is done
$100 ... EricJonas      - Just let me know how to pledge
 
== Plan ==
 
# Describe the [[Current PDF Support]]
# Identify [[Required PDF Support]]
# Assemble a few dozen examples to use as [[PDF test cases]]
# Document how each of the current existing projects (potential starting points) performs on the suite of test cases
# Determine timeframe
## Start some time in early 2006?
## Expected completion some time in mid/late 2006?
# Select developer with the right skillset
## C/C++, XML
## PDF file format
## SVG file format
## Able to work under (U.S.) contract
## /Other skillset requirements?/
# Determine what funding is needed to enable them to complete the work
# Establish a contract with the selected developer to perform the work
# When the developer is done, verify that all test cases pass, then pay developer
 
== Background Information ==
 
* [[SOC_Original_Project_Prompts]]
* PrintingSubsystem
* [[Roadmap]] (Milestone 11) Import/Export Feature Enhancements
 
== Adequate Technical Solutions ==
 
What solutions would be fine?
* Library that integrates directly in to inkscape (and scribus, ...)
** Use [[Cairo]] as the presentation layer and use its support for pdf/ps
*** See [http://poppler.freedesktop.org/ Poppler] for PDF import. 
*** This may be a first step towards an eventual migration of the backend renderer to Cairo
** Pull out the scribus pdf support into a libpdf that can be shared by both scribus and Inkscape
*** Requires conversion of Qt-isms into more neutral widgetset-independent style
* Extend an existing standalone (filter) tool that can be bundled with inkscape
** [http://scratchcomputing.com/projects/uber-converter/ Uberconverter]
** [http://www.solidcode.net/pdf2svg/ pdf2svg]
** [http://www.sodipodi.com/index.php3?section=download/tools ill2svg]
** [http://www.xs4all.nl/~hanwen/public/software/ai2svg.py ai2svg]
** [http://www.accesspdf.com/pdftk/ pdftk]
 
== Possible Strategies ==
 
* Raise money and hire a developer to implement it
** Collect pledges, once we are over threshold collect funds (http://fundable.org/)
*** What should the threshhold be?  $2000?  $5000?
*** Still too early to decide what the threshold should be.  We need to know how much it will cost first.
** Need to decide what the funds would be spent on ahead of time
*** 10-20% - Tester to collect test cases and put together a test suite for developer to use
*** 70-80% - Developer to write the code, document it, and make it pass the tests
*** 5-10%  - Liaison to handle the paperwork, collect/distribute funds, track/report progress, and verify the work has been completed adequately
** Mercenaries that would do this for us?
*** BrandonCsSanders ... I'd do it for $2000, half up front, half once it meets spec.  Caveat: it would take me six months to complete because my plate is pretty full right now and I'll be snatching a week here and a week there.
*** EricWilhelm ... This will be a lovely fit for the UberConverter.  I'm guessing $5k would get it to about the same level as XAR and SVG in chromista.  Caveat:  Those aren't done yet.  Check back in Jan.  I would also be happy to oversee/direct the work of someone else wanting to write this as a pair of UberConverter connectors (crs2pdf, pdf2crs.)
*** /other mercenaries?/
* Hold a [http://www.usemod.com/cgi-bin/mb.pl?BarnRaising BarnRaising]
** at [http://RecentChangesCamp.org RecentChangesCamp] in Portland February 3-5
** other location/time?
* Wait for a volunteer to get inspired and just do it
 
 
== Questions/Brainstorms ==
 
* What about what inkscape earned through the Google Summer of Code? What's the status of this?
** $2000 earned; there has been no plan or consensus for what to use it for
* Does Cairo have PDF export already? What about to use cairo for just this job? and later then use cairo for the whole presentation layer? Instead of creating an interims solution?
** Yes, Cairo has PDF export capabilities; it's unknown if it's significantly better than our current (poor) pdf export functionality
** Cairo Postscript and PDF backends are still experimental and disabled by default in current stable release, but plan is to make them supported in next stable release, expected for the end of 2005. See [http://cvs.cairographics.org/*checkout*/cairo/ROADMAP Cairo ROADMAP]
** A way to test cairo capabilities would be to use librsvg HEAD. See Dom Lachowicz [http://www.advogato.org/person/cinamod/diary.html?start=91 blog entry].
* Investigate ps2ai, pstoedit and ai2svg conversion options (potential EPS support?)
* Import of native Adobe Illustrator files, which have been PDF based since Illustrator 10 (at least). 
* Other RFE's related to Import or Export?
* Add extension for use of [http://vdxtosvg.sourceforge.net/ VDX2SVG]
** (This is an unrelated file format... -- Bryce)
* UberConverter
 
 
* I'd like to suggest looking at Xpdf or ghostview as possible bases to build a pdftosvg tool with. They both come with command line tools to convert pdf files to other formats. - Ulf Erikson
** This is what we do currently iirc - Bryce
** Uh, okay. I must have missed that. What tool do you use? I know about [http://www.solidcode.net/pdf2svg/ pdf2svg], [http://www.sodipodi.com/index.php3?section=download/tools ill2svg] and [http://www.xs4all.nl/~hanwen/public/software/ai2svg.py ai2svg]. Neither seem to be based on a pdf reader/viewer. I have never tried the (Windows only?) SVG plugin for [http://www.pstoedit.net/pstoedit pstoedit] and the [http://www.eprg.org/projects/SVG/ps2svg/ ps2svg] SVG driver for Ghostscript doesn't seem to be available at all. Anyway, I see now that you list [http://poppler.freedesktop.org/ Poppler] (which a pdf library based on Xpdf) as something worth looking at, so I guess you can remove my comment all together. Let me know if you wish to try my Xpdf code with Poppler. - Ulf  (Could we not use the mailing list for discussions?)

Revision as of 19:13, 26 June 2020

This is a working document showing specific near-term tasks needed for achieving the numbered milestones. It is not a wishlist of features to be included in future releases. Because people often work on whatever they feel like, only the current and current+1 releases should be taken seriously. Beyond that is mainly conjectural.

See OldRoadmap for milestones that have already been achieved.

Inkscape 0.92 ~ Infrastructure Focus

2Geom 1.0

Inkscape 1.0alpha ~ Maintenance and Optimization Focus

  • (DONE) Migration to Git
  • (DONE) Migration to GitLab
  • (DONE) Decide which Unit testing framework to use (Discussion July 2013 didn't get much traction)
    • Hackfest consensus is Google test.
  • (DONE) Set up continuous builds (e.g. Travis CI / Appveyor or gitlab)
  • (DONE) Make C++11 compiler a hard requirement
  • (DONE) Drop Autotools support (See Build system improvements)
  • (DONE) Migrate potrace to be an external dependency Done for 0.92
  • (DONE) Gtk3/UI revamp Down to bug fixing and follow-on work
  • Split out less well maintained extensions to an 'extras' package
    • Add a test suite that runs each extension against a collection of test documents
    • Possibly start doing inkscape-extras releases in conjunction with Inkscape's releases?
    • If we don't achieve this by this release, push it to 1.1 or later
  • Split tutorials and other content from the main executable, to enable them to be updated independently of our main release process
    • Need to investigate where we stand with this, and re-evaluate more precisely what we want to do this release
  • Prepatory work for expanded testing
    • Document how to do the tests
    • Create or identify a good model test case
    • Implement example unit tests for: SP objects, verbs, cmdline options, live effects, UI dialogs, UI widgets/tools, UI view, etc.
    • Start collecting regression svg files in a testing repository somewhere
  • Thorough testing of document recovery after crash. Make this more robust.
    • Need to better define what we want to test
    • How should the crash be triggered?
    • What should the document be?
    • Need to be careful about what cases we actually want to consider
  • Improved performance
    • with an empty start
    • when starting up with an existing file
    • peppering printfs in the startup logic shows that some routines that should get called one time only, actually get called multiple times
    • need to investigate if there is existing instrumentation tools that could be used to identify recursion or other causes of slowness during startup
  • Improved mailing list archive
    • Move existing archive to inkscape.org or add an archive mirror at inkscape.org ("official" inkscape information is spread out wide between different domains), this would be an improvement.
    • Consider also bringing lib2geom mailing lists?
    • inkscape: We need postmaster@inkscape.org and abuse@inkscape.org set up. Maybe as part of a mailing list refresh?
  • Set up effort to package selected branches and organize community testing around them
    • Use this initially for changes planned for landing in 1.0
    • Once we're feature-frozen for 1.0, use this mechanism for wider testing of new feature work
  • Gtk+ 3 migration: Goal is a clean, deprecation-free build
    • Stop using GtkActions. Migrate toolbars to use plain widgets, and GAction
    • Turn Inkscape into a proper Gtk::Application. Stop using Gtk::Main
    • GtkMM/C++ify and clean up toolbar code
    • Remove unused GtkAction-based widgets

Inkscape 1.0beta ~ Test Case and Documentation Writing Focus

  • Write unit test cases
    • Core functions
  • Better translations - keep track of % translations for all languages. Drive to 95% on all major languages.
  • Cleanup website and wiki
    • Move pages of value to users from wiki to the main website
    • Trim down amount of legacy material presented in the wiki
  • Coder stories
    • different stories about how to do common development tasks, like hooking in a new widget or adding support of a new SVG tag
    • have people sketch in what they know, then pass around for critique to optimize the description
    • where to store the documentation? Where would someone look?

Inkscape 1.0

  • Strict bugfix focus, with all development targeted to feature branches
  • This will be a long term stable release series

Following is a WIP draft of the post-1.0 release goals; this is not yet finalized, and should not be taken as official yet


Inkscape 1.1 ~ New Features

  • Land feature branches held for post-1.0
  • SVG Flowed Text
  • Externalize some (easy) dependencies for better modularization
    • Break libdepixelize out to its own library
    • Break libnrtype out to its own library
    • Break libuemf out to its own library
    • Switch to using libcroco as a regular dependency (not embedded in our codebase).
    • Switch to using Adaptagrams (libvpsc, libcola & libavoid) as a regular dependency
  • Complete conversion to GTK 3
    • Drop use of libgdl in place of GtkNotebook
    • Be smarter about toolbar layout so we never have invisible (but necessary) buttons off the screen.
    • Rework panels so that they resize consistently and display contents better. Consider moving back to dialogs in some cases or moving more functionality to the canvas.
  • Begin development of new plugin / extension system(s)
    • C++ API with Python bindings
    • Review the D-Bus scripting API GSoC work from 0.48 timeframe
    • Easy to create
    • Powerful enough to do LPEs, filters, etc.
    • Probably need several different APIs for different levels in the codebase, such as atop the object model, one for canvas stuff, one atop the UI, etc.
      • For object layer will require better division from UI, so it doesn't require a selection for items to operate on
    • Include a debug print of the loaded extensions/plugins/etc.
    • Establish an Extensions Center for community-collaborative sharing/reviewing/maintaining extensions
      • Core extensions are shipped with Inkscape
      • User review ranking
      • Developer review ranking
      • Auto-QC ranking (mechanical testing, and checking for docs, test cases, etc.)
    • Search the Extensions Center and install from within Inkscape
  • Switch to using Poppler's API rather than using internals (the current situation causes regular breakage with new releases of Poppler)
  • GtkMMification
  • Improved performance
    • Working with large files
    • Working with files with lots of filters
  • Consider setting up workflow (passing tests, test coverage, code review) for getting code into trunk.
    • Improve new contributor experience for getting patch reviews
    • Switch patch review software from launchpad to something like mailing list + patchwork, or phabricator
  • make msi Windows install multilingual
  • Implement application-scope actions and "remixable" user interfaces:
    • Replace "Verbs" with application-scope Gio::Action definitions.
    • Define user-interface using Gtk::Builder XML files.
    • Provide command-line "headless" access to application actions.
    • Provide documentation for all actions, and tutorial for GUI customization

Inkscape 1.2 ~ Refactoring

  • Split backend / GUI frontend
  • Flip y-coordinate to match SVG.
    • Introduce a backwards compatibility mechanism that will allow us to modify the XML representation of editing info. This is needed to bring the desktop coordinate system in line with SVG due to guideline and 3D box problems (they save desktop coordinates in the XML). This can be done either at the SP tree level or by moving to a SAX-based parser which updates the editing information as the document is parsed.