Skip to content

Latest commit

 

History

History
137 lines (102 loc) · 6.01 KB

CONTRIBUTING.md

File metadata and controls

137 lines (102 loc) · 6.01 KB
Raw

Contributing to Inkscape

Inkscape welcomes your contributions to help turn it into a fully SVG-compliant drawing program for the Open Source community.

While many developers work on fixing bugs and creating new features, it is worth strong emphasis that even non-programmers can help make Inkscape more powerful and successful. You probably already have an idea of something you'd like to work on. If not, here are just a few ways you can help:

  • Pick a bug, fix it, and send in a merge request on GitLab.
  • Choose a feature you want to see developed, and make it.
  • If you speak a language in addition to English, work on your language's i18n file in the po/ directory.
  • Find a new bug and report it.
  • Help answer questions for new Inkscapers on IRC, forum, or the mailing lists.
  • Write an article advocating Inkscape.
  • Author a HOWTO describing a trick or technique you've figured out.

Git Access

Inkscape is currently developed on Git, with the code hosted on GitLab.

We give write access out to people with proven interest in helping develop the codebase. Proving your interest is straightforward: Make two contributions and request access.

Compiling the Development Version

See http://wiki.inkscape.org/wiki/index.php/CompilingInkscape for general remarks about compiling, including how to find some of the needed packages for your distribution, and suggestions for developers.

Patch Decisions

Our motto for changes to the codebase is "Patch first, ask questions later". When someone has an idea, rather than endlessly debating it, we encourage folks to go ahead and code something up (even prototypish). You would make this change in your own fork of Inkscape (see GitLab docs about how to fork the repository), in a development branch of the code, which can be submitted to GitLab as a merge request. Once in an MR it is convenient for other folks to try out, poke and prod, and tinker with. We figure, the best way to see if an idea fits is to try it on for size. So if you have an idea, go ahead and fork Inkscape and submit a merge request! That will also take care of running build tests on the branch, although we would encourage you to check if everything builds and tests pass on your system first.

Coding Style

Please refer to the Coding Style Guidelines (https://inkscape.org/en/develop/coding-style/) if you have specific questions on the style to use for code. If reading style guidelines doesn't interest you, just follow the general style of the surrounding code, so that it is at least consistent.

Documentation

Code needs to be documented. Future Inkscape developers will really appreciate this. New files should have one or two lines describing the purpose of the code inside the file.

Building (In Linux distribution)

This is the best set of instructions for setting up your build directory...

You should install ninja and ccache for the fastest build:

sudo apt-get install ninja-build ccache

Next we prepare a build directory with a symlink to Inkscape's share folder, add a profile dir and set the bin folder (optional):

ln -s $PWD/share ./share/inkscape
mkdir -p build/conf
cd build
export INKSCAPE_PROFILE_DIR=$PWD/conf
PATH=$PWD/bin/:$PATH

Now we invoke cmake, letting it know to use our new build directory prefix, ccache and the Ninja compiler:

cmake -DCMAKE_INSTALL_PREFIX:PATH=$PWD/../ -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_BUILD_TYPE=Debug -G Ninja ..

Invoke ninja to build the code. You may also use plain gcc's make if you didn't specific -G in the command above:

ninja

Now we can run inkscape that we have built, with the latest resources and code:

./bin/inkscape

To build in Non-Linux Platforms check out INSTALL.md (Links to Inkscape Wiki pages are given right below "Basic Installation")

Profiling

To run with profiling, add -DWITH_PROFILING=ON to the above cmake script. Compiling and running will be slower and the gmon file will appear only after Inkscape quits.

See: https://wiki.inkscape.org/wiki/index.php/Profiling

Testing

Before landing a patch, the unit tests should pass.

See: http://wiki.inkscape.org/wiki/index.php/CMake#Using_CMake_to_run_tests

General Guidelines for developers

  • If you are new, fork the inkscape project (https://gitlab.com/inkscape/inkscape) and create a new branch for each bug/feature you want to work on. Try to Set the CI time to a high value like 2 hour (Go to your fork > Settings > CI/CD > General Pipelines > Timeout)
  • Merge requests (MR) are encouraged for the smallest of contributions. This helps other developers review the code you've written and check for the mistakes that may have slipped by you.
  • Before working on anything big, be sure to discuss your idea with us (IRC or RocketChat). Someone else might already have plans you can build upon and we will try to guide you !
  • Adopt the coding style (indentation, bracket placement, reference/pointer placement, variable naming etc. - developer's common sense required!) of existing source so that your changes and code doesn't stand out/feel foreign.
  • Carefully explain your ideas and the changes you've made along with their importance in the MR. Feel free to use pictures !
  • Check the "Allow commits from members who can merge to this target branch" option while submitting the MR.
  • Write informative commit messages (check this). Use full url of bug instead of mentioning just the number in messages and discussions.
  • Try to keep your MR current instead of creating a new one. Rebase your MR sometimes.
  • Inkscape has contributors/developers from across the globe. Some may be unavailable at times but be patient and we will try our best to help you. We are glad to have you!