Inkscape Wiki - User contributions [en]

PowerStroke

2021-01-24T21:14:19Z

Jnweiger: /* GUI */

= LGM 2012 Presentation =

A PDF of Johan's presentation at LGM 2012 in Vienna: [[File:LGM2012 - Powerstroke.pdf]]

SVG source files: ''should be linked here soon...''

= Power stroke =

The proposed power stroke LPE is as follow:

[[Image:Power-stroke-1.png]]

== Functionality ==

This LPE allows a modulated stroke from manually entered values.

Further development could allow direct width reading from a pressure-enabled device.

== Workflow ==

The user simply creates the line, it might for example be based on an outline.

Then the user applies the LPE to his shape, it overrides the normal stroke rendering and allows custom line width at different nodes of the path.

Only the stroke-width property of the path is overridden, the rest of the stroke properties keep working as usual, when relevant.

== GUI ==

Se image above. User selects a nodes or a set of nodes and affects values to those. When a node is selected, you can see what its value is by the change in values in the number entry or by the state of the push button.

Additionally, hovering over a node could show the value of a node. Graphical feedback could even possibly set different icons for nodes that are set and others that are interpolated.

Perhaps Alt+drag a node to change the thickness?

A combination of a metakey and the scroll wheel would be intuitive as well (with status bar message stating you can do that, of course). -- [[jegHegy]]

As of inkscape-1.0.1 the implementation is different than what is described here.
* When added, the Path Effect PowerStroke produces 3 additional pink handles that can be dragged around intuitively:
** A pink handle can be moved along the length of the path to define where it should have its effect.
** A pink handle can be dragged away from or closer to the center of the path to make the stroke at this position thicker or thinner.
* To add another pink handle, you can duplicate one of the existing ones with '''CTRL-Click''', and then drag it away along the path.
* To remove a pink handle, '''CTRL-ALT-Click''' on it.
* To position a pink handle at exact coordinates, '''ALT-Click''' on it, an entry box opens.
-- [[User:Jnweiger|Jnweiger]] ([[User talk:Jnweiger|talk]])

= Comments =

== By JohanE ==
This is very well doable, but would require a new "Nodepath" implementation that enables writing special values (preferably a struct) per node. There is already something like this, the "nodetypes" attribute, but it is too restrictive. Expanding this would enable this effect, and opens up many other possibilities. Nice idea !

== By Pajarico ==
I'm thinking this tool could allow the user to copy a path or an object or group of objects to any node in a path. Which is similar to what you're proposing, only this doesn't use interpolation between adjacent nodes, it just places an element on a specific node (or nodes if you have several selected).

I'm not sure if it is better to open a separate blueprint or not. --Pajarico, [[User:Pajarico|Pajarico]] 22:36, 21 June 2008 (UTC)

== By rubikcube ==
You might want to have a look at how [http://www.synfig.org synfig] handles varying width for paths. Paths are called "Blines" there, the relevant feature is explained shortly at the bottom of [http://synfig.org/Creating_Shapes one of its manual pages]. --[[User:Rubikcube|Rubikcube]] 17:26, 3 September 2008 (UTC)

== By Klesus ==
In concept I've been thinking of this for a long time, so I'm hopeful that this possibly could be expanded to allow control of other things than stroke width like say, stroke color, opacity and perhaps even blur(!) although I doubt blur is something that would be impossible to implement.
Just my 2 cents.

== By dvlierop ==
Can this be coupled to the pressure applied using a tablet, while drawing a line? I think this would allow to create an LPE powerstroke in the most possible intuitive way. But I'm more a CAD guy than an artist, so I might be totally off.

= Discussion at LGM 2010 =

We had a nice discussion about Power Stroke at LGM2010. Here follows some of the 'results' of the discussion and sketches...

- effect should be intuitive and simple. advanced features
that are difficult to control should be implemented in
another "advanced power stroke" effect if desired
- how to change the stroke width of multiple control points at the same time?
- width is controllable at original path's knots
- the type of width interpolation between knots should depend
on original path's knot type (smooth, cusp, etc.)
- provide options for end caps
- offer possibility of asymmetric control points
- width control handles should be perpendicular to the original path
- keep it simple and useable! don't provide the one effect to rule them all.

An interesting sketch by Ivan Louette:

[[File:powerstroke2.svg|600px]]

I have several questions about this drawing: shouldn't the edge of the stroked path always pass through the stroke width control nodes? The inverted one for example, shouldn't the stroke be 'inverted' and have the width a-b? (so the zero width stroke should happen on the left and right of the control knot?)

I propose the following:

[[File:powerstroke3.svg|600px]]

with implementation:

[[File:powerstroke3_impl.svg|400px]]

= Johan Engelen's implementation (0.48+dev) as LPE =

Since the GSoC project was stopped, Johan has begun to implement the powerstroke lpe. To test the LPE, Inkscape must be built with experimental LPE's enabled. You have to build Inkscape with
#define LPE_ENABLE_TEST_EFFECTS
otherwise the LPE won't show in the LPE dialog. (uncommenting line 9 in
src/live_effects/effect.cpp will do the trick)

[[Category:LPE]]

PowerStroke

2021-01-24T21:13:59Z

Jnweiger: /* GUI */

= LGM 2012 Presentation =

A PDF of Johan's presentation at LGM 2012 in Vienna: [[File:LGM2012 - Powerstroke.pdf]]

SVG source files: ''should be linked here soon...''

= Power stroke =

The proposed power stroke LPE is as follow:

[[Image:Power-stroke-1.png]]

== Functionality ==

This LPE allows a modulated stroke from manually entered values.

Further development could allow direct width reading from a pressure-enabled device.

== Workflow ==

The user simply creates the line, it might for example be based on an outline.

Then the user applies the LPE to his shape, it overrides the normal stroke rendering and allows custom line width at different nodes of the path.

Only the stroke-width property of the path is overridden, the rest of the stroke properties keep working as usual, when relevant.

== GUI ==

Se image above. User selects a nodes or a set of nodes and affects values to those. When a node is selected, you can see what its value is by the change in values in the number entry or by the state of the push button.

Additionally, hovering over a node could show the value of a node. Graphical feedback could even possibly set different icons for nodes that are set and others that are interpolated.

Perhaps Alt+drag a node to change the thickness?

A combination of a metakey and the scroll wheel would be intuitive as well (with status bar message stating you can do that, of course). -- [[jegHegy]]

As of inkscape-1.0.1 the implementation is different than what is described here.
* When added, the Path Effect PowerStroke produces 3 additional pink handles that can be dragged around intuitively:
** A pink handle can be moved along the length of the path to define where it should have its effect.
** A pink handle can be dragged away from or closer to the center of the path to make the stroke at this position thicker or thinner.
* To add another pink handle, you can duplicate one of the existing ones with '''CTRL-Click''', and then drag it away along the path.
* To remove a pink handle, '''CTRL-ALT-Click''' on it.
* To position a pink handle at exact coordinates, '''ALT-Click''' on it, an entry box opens.

-- [[User:Jnweiger|Jnweiger]] ([[User talk:Jnweiger|talk]])

= Comments =

== By JohanE ==
This is very well doable, but would require a new "Nodepath" implementation that enables writing special values (preferably a struct) per node. There is already something like this, the "nodetypes" attribute, but it is too restrictive. Expanding this would enable this effect, and opens up many other possibilities. Nice idea !

== By Pajarico ==
I'm thinking this tool could allow the user to copy a path or an object or group of objects to any node in a path. Which is similar to what you're proposing, only this doesn't use interpolation between adjacent nodes, it just places an element on a specific node (or nodes if you have several selected).

I'm not sure if it is better to open a separate blueprint or not. --Pajarico, [[User:Pajarico|Pajarico]] 22:36, 21 June 2008 (UTC)

== By rubikcube ==
You might want to have a look at how [http://www.synfig.org synfig] handles varying width for paths. Paths are called "Blines" there, the relevant feature is explained shortly at the bottom of [http://synfig.org/Creating_Shapes one of its manual pages]. --[[User:Rubikcube|Rubikcube]] 17:26, 3 September 2008 (UTC)

== By Klesus ==
In concept I've been thinking of this for a long time, so I'm hopeful that this possibly could be expanded to allow control of other things than stroke width like say, stroke color, opacity and perhaps even blur(!) although I doubt blur is something that would be impossible to implement.
Just my 2 cents.

== By dvlierop ==
Can this be coupled to the pressure applied using a tablet, while drawing a line? I think this would allow to create an LPE powerstroke in the most possible intuitive way. But I'm more a CAD guy than an artist, so I might be totally off.

= Discussion at LGM 2010 =

We had a nice discussion about Power Stroke at LGM2010. Here follows some of the 'results' of the discussion and sketches...

- effect should be intuitive and simple. advanced features
that are difficult to control should be implemented in
another "advanced power stroke" effect if desired
- how to change the stroke width of multiple control points at the same time?
- width is controllable at original path's knots
- the type of width interpolation between knots should depend
on original path's knot type (smooth, cusp, etc.)
- provide options for end caps
- offer possibility of asymmetric control points
- width control handles should be perpendicular to the original path
- keep it simple and useable! don't provide the one effect to rule them all.

An interesting sketch by Ivan Louette:

[[File:powerstroke2.svg|600px]]

I have several questions about this drawing: shouldn't the edge of the stroked path always pass through the stroke width control nodes? The inverted one for example, shouldn't the stroke be 'inverted' and have the width a-b? (so the zero width stroke should happen on the left and right of the control knot?)

I propose the following:

[[File:powerstroke3.svg|600px]]

with implementation:

[[File:powerstroke3_impl.svg|400px]]

= Johan Engelen's implementation (0.48+dev) as LPE =

Since the GSoC project was stopped, Johan has begun to implement the powerstroke lpe. To test the LPE, Inkscape must be built with experimental LPE's enabled. You have to build Inkscape with
#define LPE_ENABLE_TEST_EFFECTS
otherwise the LPE won't show in the LPE dialog. (uncommenting line 9 in
src/live_effects/effect.cpp will do the trick)

[[Category:LPE]]

PowerStroke

2021-01-24T21:00:40Z

Jnweiger: /* GUI */

= LGM 2012 Presentation =

A PDF of Johan's presentation at LGM 2012 in Vienna: [[File:LGM2012 - Powerstroke.pdf]]

SVG source files: ''should be linked here soon...''

= Power stroke =

The proposed power stroke LPE is as follow:

[[Image:Power-stroke-1.png]]

== Functionality ==

This LPE allows a modulated stroke from manually entered values.

Further development could allow direct width reading from a pressure-enabled device.

== Workflow ==

The user simply creates the line, it might for example be based on an outline.

Then the user applies the LPE to his shape, it overrides the normal stroke rendering and allows custom line width at different nodes of the path.

Only the stroke-width property of the path is overridden, the rest of the stroke properties keep working as usual, when relevant.

== GUI ==

Se image above. User selects a nodes or a set of nodes and affects values to those. When a node is selected, you can see what its value is by the change in values in the number entry or by the state of the push button.

Additionally, hovering over a node could show the value of a node. Graphical feedback could even possibly set different icons for nodes that are set and others that are interpolated.

Perhaps Alt+drag a node to change the thickness?

A combination of a metakey and the scroll wheel would be intuitive as well (with status bar message stating you can do that, of course). -- [[jegHegy]]

As of inkscape-1.0.1 the implementation is different than what is described here. Path Effect Powerstroke produces 3 additional pink handles that can be dragged around intuitively without any Alt or Metakey magic. A pink handle can be moved along the length of the path to define where it should have its effect. A pink handle can be dragged away from or closer to the center of the path to make the stroke at this position thicker or thinner.
To get more than 3 pink handles, you can duplicate one of them with CTRL-Click, and then drag it away along the path. -- [[User:Jnweiger|Jnweiger]] ([[User talk:Jnweiger|talk]])

= Comments =

== By JohanE ==
This is very well doable, but would require a new "Nodepath" implementation that enables writing special values (preferably a struct) per node. There is already something like this, the "nodetypes" attribute, but it is too restrictive. Expanding this would enable this effect, and opens up many other possibilities. Nice idea !

== By Pajarico ==
I'm thinking this tool could allow the user to copy a path or an object or group of objects to any node in a path. Which is similar to what you're proposing, only this doesn't use interpolation between adjacent nodes, it just places an element on a specific node (or nodes if you have several selected).

I'm not sure if it is better to open a separate blueprint or not. --Pajarico, [[User:Pajarico|Pajarico]] 22:36, 21 June 2008 (UTC)

== By rubikcube ==
You might want to have a look at how [http://www.synfig.org synfig] handles varying width for paths. Paths are called "Blines" there, the relevant feature is explained shortly at the bottom of [http://synfig.org/Creating_Shapes one of its manual pages]. --[[User:Rubikcube|Rubikcube]] 17:26, 3 September 2008 (UTC)

== By Klesus ==
In concept I've been thinking of this for a long time, so I'm hopeful that this possibly could be expanded to allow control of other things than stroke width like say, stroke color, opacity and perhaps even blur(!) although I doubt blur is something that would be impossible to implement.
Just my 2 cents.

== By dvlierop ==
Can this be coupled to the pressure applied using a tablet, while drawing a line? I think this would allow to create an LPE powerstroke in the most possible intuitive way. But I'm more a CAD guy than an artist, so I might be totally off.

= Discussion at LGM 2010 =

We had a nice discussion about Power Stroke at LGM2010. Here follows some of the 'results' of the discussion and sketches...

- effect should be intuitive and simple. advanced features
that are difficult to control should be implemented in
another "advanced power stroke" effect if desired
- how to change the stroke width of multiple control points at the same time?
- width is controllable at original path's knots
- the type of width interpolation between knots should depend
on original path's knot type (smooth, cusp, etc.)
- provide options for end caps
- offer possibility of asymmetric control points
- width control handles should be perpendicular to the original path
- keep it simple and useable! don't provide the one effect to rule them all.

An interesting sketch by Ivan Louette:

[[File:powerstroke2.svg|600px]]

I have several questions about this drawing: shouldn't the edge of the stroked path always pass through the stroke width control nodes? The inverted one for example, shouldn't the stroke be 'inverted' and have the width a-b? (so the zero width stroke should happen on the left and right of the control knot?)

I propose the following:

[[File:powerstroke3.svg|600px]]

with implementation:

[[File:powerstroke3_impl.svg|400px]]

= Johan Engelen's implementation (0.48+dev) as LPE =

Since the GSoC project was stopped, Johan has begun to implement the powerstroke lpe. To test the LPE, Inkscape must be built with experimental LPE's enabled. You have to build Inkscape with
#define LPE_ENABLE_TEST_EFFECTS
otherwise the LPE won't show in the LPE dialog. (uncommenting line 9 in
src/live_effects/effect.cpp will do the trick)

[[Category:LPE]]

Bug management

2019-05-28T07:59:30Z

Jnweiger: point to gitlab

Inkscape's bugs are reported and managed in [https://gitlab.com/inkscape/inkscape/issues GitLab].

** Text below needs update **
Inkscape's bugs formerly were reported and managed in [https://launchpad.net/ Launchpad]. Any Launchpad user can comment on bugs, update their status, and assign themselves to work on a given bug. Inkscape Bug Team members can set the bug status to Triaged (more below) and assign priorities.

==Important URLs==
*[https://bugs.launchpad.net/inkscape Inkscape Bugs] - start bug management here.
*[https://launchpad.net/~inkscape.bugs Inkscape Bug Team] - you can apply for bug team membership here.

==Bug status==

Launchpad has several bug statuses. Their use in Inkscape is explained here.

* '''New''': this bug was just reported, and it is not known whether it is reproducible. Try to reproduce this bug on your computer.
* '''Confirmed''': this bug was reproduced and verified to be Inkscape's fault. You can work on tracking it down and fixing it.
* '''Triaged''': a Bug Team member has verified the bug and assigned an importance to it. Inkscape developers accept that they will work to resolve the bug.
* '''In Progress''': someone is working right now to fix the bug. Do not use this status to indicate that you are willing to work on a given bug, or that you will work on it some time in the future; only set it if you have actually started to work on a fix.
* '''Fix Committed''': the bug is fixed in the development version (lp:inkscape branch). If you have committed a fix, but are not sure whether it works, for example if the issue only happens on a platform you don't have access to, leave as "In Progress".
* '''Fix Released''': the bug is fixed in the latest stable release of Inkscape. Also use this status for bugs that only appeared in the development version, and were never encountered in a stable release.
* '''Incomplete''': not enough information was provided by the bug reporter to adequately identify or reproduce the issue. If nobody else encounters a similar problem, it will be marked invalid after some time.
* '''Invalid''': this problem is not Inkscape's fault, or the reporter did not reply to requests for more information.
* '''Won't Fix''': issue that will never be fixed in Inkscape due to design choices or because it is out of the scope of the program. An example might be a request for editing audio clips or rewriting Inkscape in a different language.

==Bug importance==

Importance reflects how serious is the bug.

* '''Critical''': very serious incorrect behavior that will severely affect a majority of users. Examples: reproducible crashes after a common action; document data loss; document data corruption; severe regressions in functionality; build broken on more than one platform (Linux, Mac, Windows, other)
* '''High''': serious incorrect behavior that is likely to affect a large portion of users. Examples: reproducible crash after an uncommon sequence of actions; other user data loss (e.g. preference file corruption); non-SVG-compliant output; SVG-compliant documents misinterpreted; incorrect file output; major memory leak; build broken on one platform only
* '''Medium''': moderately serious incorrect behavior that is likely to affect many users. Examples: crash under very obscure or unlikely circumstances; user interface not adhering to standard guidelines; substandard quality of rendering; bad performance; minor memory leak; build issues on exotic but up to date platforms
* '''Low''': quirk or deviation from expected behavior that may affect a small portion of users. Examples: minor rendering quirk; inconvenient placement of commands; inconvenient behavior or limitation of functionality of an existing command; bad performance during obscure operations; incorrect translation; build issues on outdated platforms
* '''Wishlist''': lack of functionality that might might inconvenience some users. Examples: no autosave feature; export to exotic file format not supported; no drag and drop between Inkscape and Word

==Tags==

Tags assign bugs to categories related by subsystem, platform, or general area of functionality of Inkscape.

(TODO put list of official tags and description here)

==Advice==

The general methodology for working with bugs is as follows:

Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.

Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing -- someone may come up with a better report in comments. (In a few situations we've not been able to recreate the bug, but due to the involved assistance of the user have been able to narrow down and fix the problem, and the user's been able to do the validation.)

Clarify. If it took you some time to guess what it's about, change the summary or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it). For example "bizarro scrolling bug" should be replaced with "rendering quirk when scrolling while dragging masked clone", and "Inkscape crashes in this file" with "crash when dragging gradient stops of clone parent".

When closing a bug as Fix Committed, add a comment that includes the revision number of the first version without the bug. For bugs that appeared only in a development release and were fixed before a stable release was made, set them to "Fix Released" right after they are fixed in trunk.

Always search for similar or duplicate requests before filing new reports.
When choosing which report should be marked a duplicate and which one left valid, older reports should be given priority over newer reports. Exceptions can be made if the newer report has signficantly better information provided. Where appropriate, copy and paste across any relevant extra information as a comment to the bug report being left open.

== Bug Triage Projects ==

A list of ideas for bug triaging projects is available on the [[Projects]] page in this wiki.

[[Category:Developer Documentation]]

Compiling Inkscape on Windows with MSYS2

2019-05-27T16:17:17Z

Jnweiger: /* Building Inkscape with MSYS2 */

This page explains how to compile Inkscape on Windows using [http://www.msys2.org/ '''MSYS2'''].

MSYS2 does not only offer a convenient build environment for compiling Inkscape but also provides all necessary build tools and dependencies making it extremely simple to get started with Inkscape development.

== Installing MSYS2 ==

To set-up MSYS2 and download the necessary dependencies only two steps are required:
* '''Step 1''' — Install MSYS2
** Download the installer from the [http://www.msys2.org/ MSYS2 homepage]. Start the installation and follow the instructions on screen.
**After installation finished start an MSYS2 MSYS shell (you can work with the one launched by the installer, use the "MSYS2 MSYS" shortcut in the start menu or launch "msys2.exe" in the installation directory).
**Execute the command <code>pacman -Syu</code>. This will start a full system upgrade and ensure that you have the latest versions of all core libraries (repeat this step until no new updates are found).
* '''Step 2''' — Download dependencies
** Start an MSYS2 MinGW shell (use the "MSYS2 MinGW 32/64-bit" shortcut in the start menu or launch "mingw32/64.exe" in the installation directory). Choose the shell in this step (32-bit or 64-bit) according to whether you want to build a 32-bit or 64-bit version of Inkscape later.
** Execute the script [https://gitlab.com/inkscape/inkscape/blob/master/buildtools/msys2installdeps.sh msys2installdeps.sh] by either copy-and-pasting it into the console or by downloading it and (after changing to the folder containing the file) typing <code>./msys2installdeps.sh</code>. If you already have a copy of the Inkscape source it should also be included in the "buildtools" folder.
Step 2 will take some time to complete (approx. 10 minutes depending on the speed of your internet connection and the load of the download servers), so relax and get a cup of coffee...

== Obtaining Inkscape Source ==

''Note: For general instructions on how to use Git see [[Working with Git]].''

As MSYS2 provides the revision control software Git you do not need to download it separately. Simply open the MSYS2 MinGW shell and run the command
<pre>git clone --recurse-submodules https://gitlab.com/inkscape/inkscape.git master</pre>
This creates a folder called "master" in the current working directory (usually the home folder located at "C:\msys64\home\Your_Username" or similar) in which the clone of the source repository is created.

You can later update it with:
<pre>
git pull --recurse-submodules
</pre>

== Building Inkscape with MSYS2 ==

To compile Inkscape open the MSYS2 MinGW shell (remember to use the correct shell, i.e. 32-bit or 64-bit, matching the dependencies you downloaded above and the version of Inkscape you want to build).

An error message like `c:msys64mingw32bingcc.exe comand not found` could indicate that you should retry with the 64-bit version of MSYS2.

If needed:
* Download and install ninja from https://github.com/ninja-build/ninja/releases/ninja-win.zip
* Download and install cmake from https://github.com/Kitware/CMake/releases/download/v3.14.4/cmake-3.14.4-win64-x64.msi

Then execute the following commands:
<pre>
# change to the directory containing your Inkscape source checkout (has to be adjusted to match your system)
cd master

# create a directory for the build (could also be another folder, but we'll assume 'build' being used for the rest of the article)
mkdir build
cd build

# create build files with CMake (we generate rules for "Ninja" as it's significantly faster then "MinGW Makefiles" which uses mingw32-make)
# note the source path '..' (which in this case is the parent directory) and should always point to the root folder of your copy of the Inkscape source
cmake -G Ninja ..

# start the compilation
ninja

# install compiled files and all dependencies required to run Inkscape into the folder 'build/inkscape/'
ninja install

# The last two steps can be combined (i.e. run 'ninja install' immediately) if you want to save time in future, as the "install" target also includes the default target
</pre>

'''''That's it!''''' 
Afterwards you should have a complete binary distribution of Inkscape in the folder "build/inkscape/" that can be run on <abbr title="Please note that GTK+3 (the toolkit used for creating Inkscape's UI) has dropped support for Windows XP, so builds of master will only run on Windows Vista and later. Windows XP is still supported in the 0.92.x branch, though.">any Windows machine</abbr>.

== Packaging ==

If you only want to run Inkscape you do ''not'' need to follow these instructions. Simply execute <code>inkscape.exe</code> from the "build/inkscape/" directory created in the previous step, the <code>ninja install</code> command takes care of copying all required files into this directory.

To package those files for distribution (this should only concern package maintainers or people who want to improve the installer code) we offer a set of CMake convenience targets that can be executed as follows:
* <code>ninja dist-win-7z</code> – generate binary 7z archive. You'll need to install [http://www.7-zip.org/ 7-Zip].
* <code>ninja dist-win-exe</code> – generate .exe installer. You'll need to install [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)] version 3 or later.
* <code>ninja dist-win-msi</code> – generate .msi installer. You'll need to install [http://wixtoolset.org/ Windows Installer XML (WiX Toolset)].
* Additionally there's a <code>dist-win-all</code> target (executes all of the above in parallel) and for each of the three there's also a <code>dist-win-*-fast</code> target (which is identical in functionality but will use a faster compression method which will increase package size but will also significantly reduce packaging time which can be useful for debugging/development purposes).

For some additional details which have not been incorporated into this page yet see the previous instructions at [[Compiling Inkscape on Windows 32-bit#Creating an installer]] (might be partially oudated).

Compiling Inkscape on Windows with MSYS2

2019-05-27T13:43:35Z

Jnweiger: /* Building Inkscape with MSYS2 */

This page explains how to compile Inkscape on Windows using [http://www.msys2.org/ '''MSYS2'''].

MSYS2 does not only offer a convenient build environment for compiling Inkscape but also provides all necessary build tools and dependencies making it extremely simple to get started with Inkscape development.

== Installing MSYS2 ==

To set-up MSYS2 and download the necessary dependencies only two steps are required:
* '''Step 1''' — Install MSYS2
** Download the installer from the [http://www.msys2.org/ MSYS2 homepage]. Start the installation and follow the instructions on screen.
**After installation finished start an MSYS2 MSYS shell (you can work with the one launched by the installer, use the "MSYS2 MSYS" shortcut in the start menu or launch "msys2.exe" in the installation directory).
**Execute the command <code>pacman -Syu</code>. This will start a full system upgrade and ensure that you have the latest versions of all core libraries (repeat this step until no new updates are found).
* '''Step 2''' — Download dependencies
** Start an MSYS2 MinGW shell (use the "MSYS2 MinGW 32/64-bit" shortcut in the start menu or launch "mingw32/64.exe" in the installation directory). Choose the shell in this step (32-bit or 64-bit) according to whether you want to build a 32-bit or 64-bit version of Inkscape later.
** Execute the script [https://gitlab.com/inkscape/inkscape/blob/master/buildtools/msys2installdeps.sh msys2installdeps.sh] by either copy-and-pasting it into the console or by downloading it and (after changing to the folder containing the file) typing <code>./msys2installdeps.sh</code>. If you already have a copy of the Inkscape source it should also be included in the "buildtools" folder.
Step 2 will take some time to complete (approx. 10 minutes depending on the speed of your internet connection and the load of the download servers), so relax and get a cup of coffee...

== Obtaining Inkscape Source ==

''Note: For general instructions on how to use Git see [[Working with Git]].''

As MSYS2 provides the revision control software Git you do not need to download it separately. Simply open the MSYS2 MinGW shell and run the command
<pre>git clone --recurse-submodules https://gitlab.com/inkscape/inkscape.git master</pre>
This creates a folder called "master" in the current working directory (usually the home folder located at "C:\msys64\home\Your_Username" or similar) in which the clone of the source repository is created.

You can later update it with:
<pre>
git pull --recurse-submodules
</pre>

== Building Inkscape with MSYS2 ==

To compile Inkscape open the MSYS2 MinGW shell (remember to use the correct shell, i.e. 32-bit or 64-bit, matching the dependencies you downloaded above and the version of Inkscape you want to build).

If needed:
* Download and install ninja from https://github.com/ninja-build/ninja/releases/ninja-win.zip
* Download and install cmake from https://github.com/Kitware/CMake/releases/download/v3.14.4/cmake-3.14.4-win64-x64.msi

Then execute the following commands:
<pre>
# change to the directory containing your Inkscape source checkout (has to be adjusted to match your system)
cd master

# create a directory for the build (could also be another folder, but we'll assume 'build' being used for the rest of the article)
mkdir build
cd build

# create build files with CMake (we generate rules for "Ninja" as it's significantly faster then "MinGW Makefiles" which uses mingw32-make)
# note the source path '..' (which in this case is the parent directory) and should always point to the root folder of your copy of the Inkscape source
cmake -G Ninja ..

# start the compilation
ninja

# install compiled files and all dependencies required to run Inkscape into the folder 'build/inkscape/'
ninja install

# The last two steps can be combined (i.e. run 'ninja install' immediately) if you want to save time in future, as the "install" target also includes the default target
</pre>

'''''That's it!''''' 
Afterwards you should have a complete binary distribution of Inkscape in the folder "build/inkscape/" that can be run on <abbr title="Please note that GTK+3 (the toolkit used for creating Inkscape's UI) has dropped support for Windows XP, so builds of master will only run on Windows Vista and later. Windows XP is still supported in the 0.92.x branch, though.">any Windows machine</abbr>.

== Packaging ==

If you only want to run Inkscape you do ''not'' need to follow these instructions. Simply execute <code>inkscape.exe</code> from the "build/inkscape/" directory created in the previous step, the <code>ninja install</code> command takes care of copying all required files into this directory.

To package those files for distribution (this should only concern package maintainers or people who want to improve the installer code) we offer a set of CMake convenience targets that can be executed as follows:
* <code>ninja dist-win-7z</code> – generate binary 7z archive. You'll need to install [http://www.7-zip.org/ 7-Zip].
* <code>ninja dist-win-exe</code> – generate .exe installer. You'll need to install [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)] version 3 or later.
* <code>ninja dist-win-msi</code> – generate .msi installer. You'll need to install [http://wixtoolset.org/ Windows Installer XML (WiX Toolset)].
* Additionally there's a <code>dist-win-all</code> target (executes all of the above in parallel) and for each of the three there's also a <code>dist-win-*-fast</code> target (which is identical in functionality but will use a faster compression method which will increase package size but will also significantly reduce packaging time which can be useful for debugging/development purposes).

For some additional details which have not been incorporated into this page yet see the previous instructions at [[Compiling Inkscape on Windows 32-bit#Creating an installer]] (might be partially oudated).

Hackfest2019 Saarbrücken Attendees

2019-05-25T18:56:27Z

Jnweiger: /* Who is Attending? */

Other pages: [[Hackfest2019 Saarbrücken]], [[Hackfest2019 Saarbrücken Topics]], [[Hackfest2019 SCALE]].

Note:

For the 27th and 28th, there can be no more than 20 persons in k8's office! If there are more, they would need to find a different place to meet (e.g. in a hotel room, or ask someone local).

On 29th, those persons that staff the booth in the Open Source event can be discounted from the cap (currently 3).

== Who is Attending? ==

{| class="wikitable" style="text-align: center;"
|+ List of Attendees
Hackfest
|-
! rowspan="2" | Who
! rowspan="2" | Dates
! rowspan="2" | Maximum Allocation
! colspan="2" | Arrival
! colspan="2" | Departure
! rowspan="2" | Hotel
|-
! Date/Time
! Detail
! Date/Time
! Detail
|-
| Tavmjong Bah
| 5/27, 5/28, 5/29, 5/30, 6/1, (6/2)
| Per SFC Rules
| 5/26 Evening
| By car?
| 6/2 Afternoon
| By car?
| 50 Nauwieserstraßa (Apartment)
|-
| Thomas Holder
| 5/27, 5/28, 5/29
| Per SFC Rules
| 5/26 16:15
| RE 4127 (train)
| 5/29 18:59
| ICE 9555 (train)
| Airbnb
|-
| Jabier Arraiza
| 5/27, 5/28, 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Mihaela Jurković
| 5/28 (?), 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Marc Jeanmougin
| 
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Jürgen Weigert
| all
| Per SFC rules
|  5/26
|  by car
|  6/02
| 
|  Zur Klause
|-
| Tobias Ellinghaus
| 
| (no travel or accomodation assistance is needed)
| local
| 
| local
| 
| local
|-
| Cédric Gémy
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Elisa de Castro Guerra
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Boudewijn Rempt
| All
| (no travel or accomodation assistance is needed)
| 26.05 16:41
| RE 4116
| 03.06 10:58
| TGV 9551
| Mercure Hotel Saarbrücken City
|-
| René de Hesselle
| 5/27, 5/28, 5/29
| Per SFC rules
| 27.05. 12:00
| car (likely)
| 29.05. 20:00
| car (likely)
| Motel One
|-
| Max Gaukler
| 5/27, 5/28, 5/29
| (no travel or accomodation assistance is needed)
| 
| 
| 
| 
| 
|-
| Alex Valavanis
| 5/27, 5/28, 5/29
| Per SFC rules
| 5/26 1400 (Frankfurt)
| LH943 (Manchester to Frankfurt)
| 5/30 1650 (Frankfurt)
| LH946 (Frankfurt to Manchester)
| Motel One
|-
| Sample Person
| 
| TBD
| 
| 
| 
| 
| 
|-! Total
!
!
! $ TBD
!
!
!
!
!
|}

TBD: "To Be Determined"

The Inkscape board has approved travel reimbursements of up to $2000 per person. Note: participants require the formality of a board vote.

Separate allocations for:
* Inkscape dinner, participants and guests (300€).
* Snacks, etc. (100€).
* Venue: Free.

1 Requires formality of board vote.

== Unconfirmed but Likely Attendees ==

* Alexandre Prokoudine (during LGM as visitor/guest)

== Maybe ==

* ede123 (Patrick)
* Thomas Wiesner (@wiesi on gitlab, python console, attendence very unlikely)

== People to Invite ==

* Shlomi Fish
* Anatoly (@techtonik on gitlab)
* Olli (https://gitlab.com/ollip)
* Emmanuel Gil Peyrot (https://gitlab.com/linkmauve)
* Khaled Hosny (font expert)
* Antonio Hospite (https://gitlab.com/ao2)
* Michael Soegtrop (https://gitlab.com/users/MSoegtrop)
* Simon Wells (https://gitlab.com/xzcvczx)
* Nicolas

* Juan Duarte (see chat.inkscape.org) - invited for LGM via chat
* Sebastian Wüst (plotting expert https://www.timewasters-place.com/) - invited via email

* probono - invited via chat
* Markus Schwienbacher - invited via gitlab
* su_v - invited via email

* <s>Sven Ebert (aka Dillerkind) - invited via forum</s>
* <s>Johan Engelen - invited via email, can't attend</s>
* <s>Martin Owens: can't attend</s>
* <s>Bryce Harrington: can't attend</s>

Possible others?
* people on the mac-devel channel

== Organizational info ==

We need to report the rough number of attendees to k8 by mid
May.

Hackfest2019 Saarbrücken Attendees

2019-05-25T10:55:14Z

Jnweiger: /* Who is Attending? */

Other pages: [[Hackfest2019 Saarbrücken]], [[Hackfest2019 Saarbrücken Topics]], [[Hackfest2019 SCALE]].

Note:

For the 27th and 28th, there can be no more than 20 persons in k8's office! If there are more, they would need to find a different place to meet (e.g. in a hotel room, or ask someone local).

On 29th, those persons that staff the booth in the Open Source event can be discounted from the cap (currently 3).

== Who is Attending? ==

{| class="wikitable" style="text-align: center;"
|+ List of Attendees
Hackfest
|-
! rowspan="2" | Who
! rowspan="2" | Dates
! rowspan="2" | Maximum Allocation
! colspan="2" | Arrival
! colspan="2" | Departure
! rowspan="2" | Hotel
|-
! Date/Time
! Detail
! Date/Time
! Detail
|-
| Tavmjong Bah
| 5/27, 5/28, 5/29, 5/30, 6/1, (6/2)
| Per SFC Rules
| 5/26 Evening
| By car?
| 6/2 Afternoon
| By car?
| 50 Nauwieserstraßa (Apartment)
|-
| Thomas Holder
| 5/27, 5/28, 5/29
| Per SFC Rules
| 5/26 16:15
| RE 4127 (train)
| 5/29 18:59
| ICE 9555 (train)
| Airbnb
|-
| Jabier Arraiza
| 5/27, 5/28, 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Mihaela Jurković
| 5/28 (?), 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Marc Jeanmougin
| 
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Jürgen Weigert
| all
| Per SFC rules
|  5/26
|  by car
|  6/03
| 
|  Zur Klause
|-
| Tobias Ellinghaus
| 
| (no travel or accomodation assistance is needed)
| local
| 
| local
| 
| local
|-
| Cédric Gémy
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Elisa de Castro Guerra
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Boudewijn Rempt
| All
| (no travel or accomodation assistance is needed)
| 26.05 16:41
| RE 4116
| 03.06 10:58
| TGV 9551
| Mercure Hotel Saarbrücken City
|-
| René de Hesselle
| 5/27, 5/28, 5/29
| Per SFC rules
| 27.05. 12:00
| car (likely)
| 29.05. 20:00
| car (likely)
| Motel One
|-
| Max Gaukler
| 5/27, 5/28, 5/29
| (no travel or accomodation assistance is needed)
| 
| 
| 
| 
| 
|-
| Alex Valavanis
| 5/27, 5/28, 5/29
| Per SFC rules
| 5/26 1400 (Frankfurt)
| LH943 (Manchester to Frankfurt)
| 5/30 1650 (Frankfurt)
| LH946 (Frankfurt to Manchester)
| Motel One
|-
| Sample Person
| 
| TBD
| 
| 
| 
| 
| 
|-! Total
!
!
! $ TBD
!
!
!
!
!
|}

TBD: "To Be Determined"

The Inkscape board has approved travel reimbursements of up to $2000 per person. Note: participants require the formality of a board vote.

Separate allocations for:
* Inkscape dinner, participants and guests (300€).
* Snacks, etc. (100€).
* Venue: Free.

1 Requires formality of board vote.

== Unconfirmed but Likely Attendees ==

* Alexandre Prokoudine (during LGM as visitor/guest)

== Maybe ==

* ede123 (Patrick)
* Thomas Wiesner (@wiesi on gitlab, python console, attendence very unlikely)

== People to Invite ==

* Shlomi Fish
* Anatoly (@techtonik on gitlab)
* Olli (https://gitlab.com/ollip)
* Emmanuel Gil Peyrot (https://gitlab.com/linkmauve)
* Khaled Hosny (font expert)
* Antonio Hospite (https://gitlab.com/ao2)
* Michael Soegtrop (https://gitlab.com/users/MSoegtrop)
* Simon Wells (https://gitlab.com/xzcvczx)
* Nicolas

* Juan Duarte (see chat.inkscape.org) - invited for LGM via chat
* Sebastian Wüst (plotting expert https://www.timewasters-place.com/) - invited via email

* probono - invited via chat
* Markus Schwienbacher - invited via gitlab
* su_v - invited via email

* <s>Sven Ebert (aka Dillerkind) - invited via forum</s>
* <s>Johan Engelen - invited via email, can't attend</s>
* <s>Martin Owens: can't attend</s>
* <s>Bryce Harrington: can't attend</s>

Possible others?
* people on the mac-devel channel

== Organizational info ==

We need to report the rough number of attendees to k8 by mid
May.

Hackfest2019 Saarbrücken Attendees

2019-05-25T10:54:36Z

Jnweiger: /* Who is Attending? */

Other pages: [[Hackfest2019 Saarbrücken]], [[Hackfest2019 Saarbrücken Topics]], [[Hackfest2019 SCALE]].

Note:

For the 27th and 28th, there can be no more than 20 persons in k8's office! If there are more, they would need to find a different place to meet (e.g. in a hotel room, or ask someone local).

On 29th, those persons that staff the booth in the Open Source event can be discounted from the cap (currently 3).

== Who is Attending? ==

{| class="wikitable" style="text-align: center;"
|+ List of Attendees
Hackfest
|-
! rowspan="2" | Who
! rowspan="2" | Dates
! rowspan="2" | Maximum Allocation
! colspan="2" | Arrival
! colspan="2" | Departure
! rowspan="2" | Hotel
|-
! Date/Time
! Detail
! Date/Time
! Detail
|-
| Tavmjong Bah
| 5/27, 5/28, 5/29, 5/30, 6/1, (6/2)
| Per SFC Rules
| 5/26 Evening
| By car?
| 6/2 Afternoon
| By car?
| 50 Nauwieserstraßa (Apartment)
|-
| Thomas Holder
| 5/27, 5/28, 5/29
| Per SFC Rules
| 5/26 16:15
| RE 4127 (train)
| 5/29 18:59
| ICE 9555 (train)
| Airbnb
|-
| Jabier Arraiza
| 5/27, 5/28, 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Mihaela Jurković
| 5/28 (?), 5/29, 5/30, 6/1, 6/2
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Marc Jeanmougin
| 
| Per SFC rules
| 
| 
| 
| 
| 
|-
| Jürgen Weigert
| 5/27 though 6/03
| Per SFC rules
|  5/26
|  by car
|  6/03
| 
|  Zur Klause
|-
| Tobias Ellinghaus
| 
| (no travel or accomodation assistance is needed)
| local
| 
| local
| 
| local
|-
| Cédric Gémy
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Elisa de Castro Guerra
| 
| Per SFC rules
|  5/28 (evening)
| 
| 
| 
| 
|-
| Boudewijn Rempt
| All
| (no travel or accomodation assistance is needed)
| 26.05 16:41
| RE 4116
| 03.06 10:58
| TGV 9551
| Mercure Hotel Saarbrücken City
|-
| René de Hesselle
| 5/27, 5/28, 5/29
| Per SFC rules
| 27.05. 12:00
| car (likely)
| 29.05. 20:00
| car (likely)
| Motel One
|-
| Max Gaukler
| 5/27, 5/28, 5/29
| (no travel or accomodation assistance is needed)
| 
| 
| 
| 
| 
|-
| Alex Valavanis
| 5/27, 5/28, 5/29
| Per SFC rules
| 5/26 1400 (Frankfurt)
| LH943 (Manchester to Frankfurt)
| 5/30 1650 (Frankfurt)
| LH946 (Frankfurt to Manchester)
| Motel One
|-
| Sample Person
| 
| TBD
| 
| 
| 
| 
| 
|-! Total
!
!
! $ TBD
!
!
!
!
!
|}

TBD: "To Be Determined"

The Inkscape board has approved travel reimbursements of up to $2000 per person. Note: participants require the formality of a board vote.

Separate allocations for:
* Inkscape dinner, participants and guests (300€).
* Snacks, etc. (100€).
* Venue: Free.

1 Requires formality of board vote.

== Unconfirmed but Likely Attendees ==

* Alexandre Prokoudine (during LGM as visitor/guest)

== Maybe ==

* ede123 (Patrick)
* Thomas Wiesner (@wiesi on gitlab, python console, attendence very unlikely)

== People to Invite ==

* Shlomi Fish
* Anatoly (@techtonik on gitlab)
* Olli (https://gitlab.com/ollip)
* Emmanuel Gil Peyrot (https://gitlab.com/linkmauve)
* Khaled Hosny (font expert)
* Antonio Hospite (https://gitlab.com/ao2)
* Michael Soegtrop (https://gitlab.com/users/MSoegtrop)
* Simon Wells (https://gitlab.com/xzcvczx)
* Nicolas

* Juan Duarte (see chat.inkscape.org) - invited for LGM via chat
* Sebastian Wüst (plotting expert https://www.timewasters-place.com/) - invited via email

* probono - invited via chat
* Markus Schwienbacher - invited via gitlab
* su_v - invited via email

* <s>Sven Ebert (aka Dillerkind) - invited via forum</s>
* <s>Johan Engelen - invited via email, can't attend</s>
* <s>Martin Owens: can't attend</s>
* <s>Bryce Harrington: can't attend</s>

Possible others?
* people on the mac-devel channel

== Organizational info ==

We need to report the rough number of attendees to k8 by mid
May.

Hackfest2019 Saarbrücken Attendees

2019-03-21T09:38:45Z

Jnweiger: /* Unconfirmed but Likely Attendees */

Other pages: [[Hackfest2019 Saarbrücken]], [[Hackfest2019 Saarbrücken Topics]], [[Hackfest2019 SCALE]].

== Confirmed Attendees ==

* Boudewijn Rempt (no travel or accomodation assistance is needed)
* Cedric and Elisa (arrival 28th evening)
* Tavmjong Bah (27th-2nd, may need to leave on 1st)
* Thomas Holder (27-29)
* Jabier Arraiza (27th-2nd)

== Unconfirmed but Likely Attendees ==

* Marc Jeanmougin
* Jürgen Weigert (arrival May-26th afternoon)
* Max Gaukler
* Tobias Ellinghaus (houz) - local
* Maren Hachmann
* Mihaela Jurković (prkos) (Tue 28? - Sun 02)

== Maybe ==

== People to Invite ==

* ede123 (Patrick)
* Shlomi Fish
* <s>Martin Owens: can't attend</s>
* Anatoly (@techtonik on gitlab)
* Thomas Wiesner (@wiesi on gitlab)
* Juan Duarte (see chat.inkscape.org)
* Olli (https://gitlab.com/ollip)
* Alex Valavanis
* Emmanuel Gil Peyrot (https://gitlab.com/linkmauve)
* Sebastian Wüst (plotting expert https://www.timewasters-place.com/)
* Alexandre Prokoudine (as guest? Might be there anyway.)
* Khaled Hosny (font expert)
* Antonio Hospite (https://gitlab.com/ao2)
* Michael Soegtrop (https://gitlab.com/users/MSoegtrop)
* Simon Wells (https://gitlab.com/xzcvczx)
* probono
* Nicolas
* su_v
* Johan Engelen
* Bryce Harrington

Possible others?
* people on the mac-devel channel

== Organizational info ==

We need to report the rough number of attendees to k8 by mid
May.

Hackfest2019 Saarbrücken Attendees

2019-01-05T13:42:31Z

Jnweiger: /* Unconfirmed but Likely Attendees */

Other pages: [[Hackfest2019 Saarbrücken]], [[Hackfest2019 Saarbrücken Topics]], [[Hackfest2019 SCALE]].

== Confirmed Attendees ==

== Unconfirmed but Likely Attendees ==

* Marc Jeanmougin
* Tavmjong Bah
* Jürgen Weigert (arrival May-29th afternoon)

== People to Invite ==

Suggestions:

* ede123 (Patrick)
* speleo3 (Thomas Holder)
* Max Gaukler
* Jürgen Weigert
* prkos (Mihaela)
* Shlomi Fish
* Jabier
* Martin Owens
* Anatoly (@techtonik on gitlab)
* Thomas Wiesner (@wiesi on gitlab)
* Juan Duarte (see chat.inkscape.org)
* Olli (https://gitlab.com/ollip)
* Alex Valavanis
* Emmanuel Gil Peyrot (https://gitlab.com/linkmauve)
* Sebastian Wüst (plotting expert https://www.timewasters-place.com/)
* Alexandre Prokoudine (as guest? Might be there anyway.)
* Khaled Hosny (font expert)
* Antonio Hospite (https://gitlab.com/ao2)
* Michael Soegtrop (https://gitlab.com/users/MSoegtrop)

(Nicolas/su_v/Johan Engelen?)

Working with Git

2018-09-10T11:36:06Z

Jnweiger: /* Cheat sheet for Bazaar users */

This page contains an introduction to the Git distributed version control system. For now, it is mainly useful to Bazaar users, but will be updated with general Git information over time.

== Git commands for the novice ==

* <code>git status</code> — Returns status of your local repository.
* <code>git pull</code> — Updates local repository from remote repository.
* <code>git pull --recurse-submodules</code> — Updates local repository including all submodules (yes, inkscape has submodules since the 1.0 release)
* <code>git pull --rebase</code> — Updates local repository moving any local commits after any pulled commits. Good for keeping things in order when you push your commits.
* <code>git add</code> — Add files to the list that will be committed.
* <code>git commit</code> — Commit your changes locally (after adding).
* <code>git push</code> — Push your locally committed changes to remote repository.
* <code>git remote -v</code> — Shows remote repository (should be: origin git@gitlab.com:inkscape/inkscape.git).
* <code>git checkout filename</code> — Reverts 'filename' to repository version.
* <code>git stash</code> — Move changes in directory out of the way (in order to 'pull' in changes).
* <code>git stash pop</code> — Restore changes stashed by 'git stash'.
* <code>git diff xxxxx yyyyy</code> — Difference between xxxxx and yyyyy.
* <code>git diff HEAD^</code> — Examine last commit.
* <code>git diff HEAD^^ HEAD^</code> — Examine second to last commit.

== Cheat sheet for Bazaar users ==
Historical reference. We no longer use bazaar.

{| class="wikitable"
!Bazaar command
!Git command
|-
| class="mw-code" |bzr branch ''branch-url''
| class="mw-code" |git clone ''repository-url'' ''directory'' cd ''directory'' git checkout ''branch-name''
|-
| class="mw-code" |bzr checkout lp:project-name
| not supported
|-
| class="mw-code" |bzr update
| not supported
|-
| class="mw-code" |bzr pull
| class="mw-code" |git pull
|-
| class="mw-code" |bzr add ''file''
| class="mw-code" |git add ''file''
|-
| class="mw-code" |bzr diff
| class="mw-code" |git diff HEAD
|-
| class="mw-code" |bzr revert
| class="mw-code" |git reset --hard
|-
| class="mw-code" |bzr revert ''file'' -r ''revision''
| class="mw-code" |git checkout ''commit'' -- ''file''
|-
| class="mw-code" |bzr uncommit
| class="mw-code" |git reset HEAD^
|-
| class="mw-code" |bzr uncommit ...some changes... bzr commit --local
| class="mw-code" |...some changes... git commit -a --amend
|-
| class="mw-code" |bzr push ''location''
| class="mw-code" |git remote add ''remote-name'' ''location'' git push ''remote-name'' ''branch-name''
|-
| class="mw-code" |bzr commit --local
| class="mw-code" |git commit -a
|-
| class="mw-code" |bzr commit
| class="mw-code" |git commit -a git push
|-
| class="mw-code" |bzr log -c 10
| class="mw-code" |git log -n 10
|-
| class="mw-code" |bzr switch ''branch-url''
| class="mw-code" |git checkout ''branch-name''
|-
| class="mw-code" |bzr switch -b ''branch-url''
| class="mw-code" |git checkout -b ''branch-name''
|-
| class="mw-code" |bzr merge ''branch-url''
| class="mw-code" |git merge ''branch-name''
|-
| class="mw-code" |bzr shelve --all
| class="mw-code" |git stash
|-
| class="mw-code" |bzr unshelve ''change-id''
| class="mw-code" |git stash pop
|}

===Other cheatsheets===

* [http://rogerdudler.github.io/git-guide/ git - the simple guide] - short and sweet, enough to get started

==Differences from Bazaar==

Here are the most important differences between Bazaar and Git:
* Bazaar revisions are identified by sequential numbers. Git revisions (called commits in the documentation) are identified by cryptographic hashes which are strings of 40 hexadecimal numbers, though it is possible to also refer to them by a sequential number since the last tag (see <code>git describe</code>).
* Bazaar is branch-oriented, while Git is repository- and commit-oriented. Repositories in Bazaar are storage locations for potentially multiple branches. Repositories in Git are collections of commits, and branches are just pointers to particular commits that are updated after each <code>git commit</code> command. Cloning a Git repository by default retrieves all of its commits and branches.
* In Bazaar, you conceptually submit your work to only one place - the push branch. You can change this place at any time, but Bazaar remembers only one value for you. In Git, you can configure many remote repositories and work with code from multiple sources using a single working tree.
* By default, each branch in Bazaar has a separate working tree, while all branches in the same Git repository share the same working tree. It's possible to make Bazaar work in the latter mode as well, but it's not very well supported.

In Bazaar, if you want to try out someone else's code, you need to create a new checkout of their branch or use <code>bzr switch</code>. In Git, what you do depends on where the code is located.
* If the code to try out is in a branch in the project's main repository, you update the repository (<code>git fetch</code>) and then check out the branch (<code>git checkout origin/branch-to-try-out</code>). This creates a local branch called <code>branch-to-try-out</code>. (You can use a different name as well.)
* If the code is in a different repository, you first add it as a remote repository with <code>git remote add ''remote-name'' ''repository-url''</code>, fetch it with <code>git fetch ''remote-name''</code> and check out the relevant branch with <code>git checkout ''remote-name''/''branch-to-try-out''</code>.

Another difference is that in Git, you cannot directly make changes to remote branches - you must to use <code>git push</code> and <code>git pull</code>. Therefore, the Subversion-like checkout mode known from Bazaar is unsupported.

==Ideas for an efficient workflow==

Here are some ideas on how you can increase your efficiency when working with git and/or achieve a workflow similar to what you were used to with Bazaar

===Download single branches or shallow clones===

By default <code>git clone https://gitlab.com/inkscape/inkscape.git</code> will download all commits from all branches (currently ~ 1.5 GB).

====Single branches====
If you're only interested in a single branch use
git clone --single-branch [--branch <name>]
which downloads only the files and history for the specified branch. Omit <code>--branch</code> to download trunk / master (currently ~ 900 MB).

====Shallow clones (no history)====
If you're not interested in commit history and only want to download the latest files use
git clone --depth 1 [--branch <name>]
which downloads only the latest revision of the specified branch. Omit <code>--branch</code> to download the latest revision of trunk / master (currently ~ 30 MB).

===Checkout multiple branches into different folders===

As git branches are all stored in the same repository you'll only have one "working tree" (the set of files making up the branch) in the beginning and switching to another branch will modify all files on disk. To have multiple branches (say trunk and 0.92.x) checked out at the same time you can obviously clone the repository multiple times. However it's much more elegant to use the [https://git-scm.com/docs/git-worktree git-worktree] command which links a new working tree to your repository that can be on any branch you want. For example
git worktree add 0.92.x_files 0.92.x
will create a working tree for the ''0.92.x'' branch in the folder ''"0.92.x_files"''. You can then use this new working tree exactly like you'd use the main working tree. (You'll need to run <code>git checkout 0.92.x</code> to set the branch.)

===Use ccache to speed up compilation after switching branches===

As git [https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F does not preserve file modification times] you'd have to do a lot of recompiling whenever switching branches (unless you use the method [[#Checkout multiple branches into different folders|described above]] for all your branches). This can be avoided by using [https://ccache.samba.org/ ccache]. There are many ways to use ccache (search the Internet!). A convenient way when using CMake are the [https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_LAUNCHER.html#variable:CMAKE_%3CLANG%3E_COMPILER_LAUNCHER <code>CMAKE_<LANG>_COMPILER_LAUNCHER</code>] variables (needs CMake 3.4 or later).

Just run CMake with the additional arguments <code>-DCMAKE_C_COMPILER_LAUNCHER="ccache" -DCMAKE_CXX_COMPILER_LAUNCHER="ccache"</code> or use any other way you prefer to set the two variables accordingly.

Working with Git

2018-09-10T11:08:32Z

Jnweiger: /* Git commands for the novice */

This page contains an introduction to the Git distributed version control system. For now, it is mainly useful to Bazaar users, but will be updated with general Git information over time.

== Git commands for the novice ==

* <code>git status</code> — Returns status of your local repository.
* <code>git pull</code> — Updates local repository from remote repository.
* <code>git pull --recurse-submodules</code> — Updates local repository including all submodules (yes, inkscape has submodules since the 1.0 release)
* <code>git pull --rebase</code> — Updates local repository moving any local commits after any pulled commits. Good for keeping things in order when you push your commits.
* <code>git add</code> — Add files to the list that will be committed.
* <code>git commit</code> — Commit your changes locally (after adding).
* <code>git push</code> — Push your locally committed changes to remote repository.
* <code>git remote -v</code> — Shows remote repository (should be: origin git@gitlab.com:inkscape/inkscape.git).
* <code>git checkout filename</code> — Reverts 'filename' to repository version.
* <code>git stash</code> — Move changes in directory out of the way (in order to 'pull' in changes).
* <code>git stash pop</code> — Restore changes stashed by 'git stash'.
* <code>git diff xxxxx yyyyy</code> — Difference between xxxxx and yyyyy.
* <code>git diff HEAD^</code> — Examine last commit.
* <code>git diff HEAD^^ HEAD^</code> — Examine second to last commit.

== Cheat sheet for Bazaar users ==

{| class="wikitable"
!Bazaar command
!Git command
|-
| class="mw-code" |bzr branch ''branch-url''
| class="mw-code" |git clone ''repository-url'' ''directory'' cd ''directory'' git checkout ''branch-name''
|-
| class="mw-code" |bzr checkout lp:project-name
| not supported
|-
| class="mw-code" |bzr update
| not supported
|-
| class="mw-code" |bzr pull
| class="mw-code" |git pull
|-
| class="mw-code" |bzr add ''file''
| class="mw-code" |git add ''file''
|-
| class="mw-code" |bzr diff
| class="mw-code" |git diff HEAD
|-
| class="mw-code" |bzr revert
| class="mw-code" |git reset --hard
|-
| class="mw-code" |bzr revert ''file'' -r ''revision''
| class="mw-code" |git checkout ''commit'' -- ''file''
|-
| class="mw-code" |bzr uncommit
| class="mw-code" |git reset HEAD^
|-
| class="mw-code" |bzr uncommit ...some changes... bzr commit --local
| class="mw-code" |...some changes... git commit -a --amend
|-
| class="mw-code" |bzr push ''location''
| class="mw-code" |git remote add ''remote-name'' ''location'' git push ''remote-name'' ''branch-name''
|-
| class="mw-code" |bzr commit --local
| class="mw-code" |git commit -a
|-
| class="mw-code" |bzr commit
| class="mw-code" |git commit -a git push
|-
| class="mw-code" |bzr log -c 10
| class="mw-code" |git log -n 10
|-
| class="mw-code" |bzr switch ''branch-url''
| class="mw-code" |git checkout ''branch-name''
|-
| class="mw-code" |bzr switch -b ''branch-url''
| class="mw-code" |git checkout -b ''branch-name''
|-
| class="mw-code" |bzr merge ''branch-url''
| class="mw-code" |git merge ''branch-name''
|-
| class="mw-code" |bzr shelve --all
| class="mw-code" |git stash
|-
| class="mw-code" |bzr unshelve ''change-id''
| class="mw-code" |git stash pop
|}

===Other cheatsheets===

* [http://rogerdudler.github.io/git-guide/ git - the simple guide] - short and sweet, enough to get started

==Differences from Bazaar==

Here are the most important differences between Bazaar and Git:
* Bazaar revisions are identified by sequential numbers. Git revisions (called commits in the documentation) are identified by cryptographic hashes which are strings of 40 hexadecimal numbers, though it is possible to also refer to them by a sequential number since the last tag (see <code>git describe</code>).
* Bazaar is branch-oriented, while Git is repository- and commit-oriented. Repositories in Bazaar are storage locations for potentially multiple branches. Repositories in Git are collections of commits, and branches are just pointers to particular commits that are updated after each <code>git commit</code> command. Cloning a Git repository by default retrieves all of its commits and branches.
* In Bazaar, you conceptually submit your work to only one place - the push branch. You can change this place at any time, but Bazaar remembers only one value for you. In Git, you can configure many remote repositories and work with code from multiple sources using a single working tree.
* By default, each branch in Bazaar has a separate working tree, while all branches in the same Git repository share the same working tree. It's possible to make Bazaar work in the latter mode as well, but it's not very well supported.

In Bazaar, if you want to try out someone else's code, you need to create a new checkout of their branch or use <code>bzr switch</code>. In Git, what you do depends on where the code is located.
* If the code to try out is in a branch in the project's main repository, you update the repository (<code>git fetch</code>) and then check out the branch (<code>git checkout origin/branch-to-try-out</code>). This creates a local branch called <code>branch-to-try-out</code>. (You can use a different name as well.)
* If the code is in a different repository, you first add it as a remote repository with <code>git remote add ''remote-name'' ''repository-url''</code>, fetch it with <code>git fetch ''remote-name''</code> and check out the relevant branch with <code>git checkout ''remote-name''/''branch-to-try-out''</code>.

Another difference is that in Git, you cannot directly make changes to remote branches - you must to use <code>git push</code> and <code>git pull</code>. Therefore, the Subversion-like checkout mode known from Bazaar is unsupported.

==Ideas for an efficient workflow==

Here are some ideas on how you can increase your efficiency when working with git and/or achieve a workflow similar to what you were used to with Bazaar

===Download single branches or shallow clones===

By default <code>git clone https://gitlab.com/inkscape/inkscape.git</code> will download all commits from all branches (currently ~ 1.5 GB).

====Single branches====
If you're only interested in a single branch use
git clone --single-branch [--branch <name>]
which downloads only the files and history for the specified branch. Omit <code>--branch</code> to download trunk / master (currently ~ 900 MB).

====Shallow clones (no history)====
If you're not interested in commit history and only want to download the latest files use
git clone --depth 1 [--branch <name>]
which downloads only the latest revision of the specified branch. Omit <code>--branch</code> to download the latest revision of trunk / master (currently ~ 30 MB).

===Checkout multiple branches into different folders===

As git branches are all stored in the same repository you'll only have one "working tree" (the set of files making up the branch) in the beginning and switching to another branch will modify all files on disk. To have multiple branches (say trunk and 0.92.x) checked out at the same time you can obviously clone the repository multiple times. However it's much more elegant to use the [https://git-scm.com/docs/git-worktree git-worktree] command which links a new working tree to your repository that can be on any branch you want. For example
git worktree add 0.92.x_files 0.92.x
will create a working tree for the ''0.92.x'' branch in the folder ''"0.92.x_files"''. You can then use this new working tree exactly like you'd use the main working tree. (You'll need to run <code>git checkout 0.92.x</code> to set the branch.)

===Use ccache to speed up compilation after switching branches===

As git [https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F does not preserve file modification times] you'd have to do a lot of recompiling whenever switching branches (unless you use the method [[#Checkout multiple branches into different folders|described above]] for all your branches). This can be avoided by using [https://ccache.samba.org/ ccache]. There are many ways to use ccache (search the Internet!). A convenient way when using CMake are the [https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_LAUNCHER.html#variable:CMAKE_%3CLANG%3E_COMPILER_LAUNCHER <code>CMAKE_<LANG>_COMPILER_LAUNCHER</code>] variables (needs CMake 3.4 or later).

Just run CMake with the additional arguments <code>-DCMAKE_C_COMPILER_LAUNCHER="ccache" -DCMAKE_CXX_COMPILER_LAUNCHER="ccache"</code> or use any other way you prefer to set the two variables accordingly.

Working with Git

2018-09-10T11:06:33Z

Jnweiger: /* Git commands for the novice */

This page contains an introduction to the Git distributed version control system. For now, it is mainly useful to Bazaar users, but will be updated with general Git information over time.

== Git commands for the novice ==

* <code>git status</code> — Returns status of your local repository.
* <code>git pull</code> — Updates local repository from remote repository.
* <code>git pull --recurse-submodules</code> — Updates local repository including all submodules (yes, inkscape has submodules since the 1.0 release)
* <code>git pull --rebase</code> — Updates local repository moving any local commits after any pulled commits. Good for keeping things in order when you push your commits.
* <code>git add</code> — Add files to the list that will be committed.
* <code>git commit</code> — Commit your changes locally (after adding).
* <code>git push</code> — Push your locally committed changes to remote repository.
* <code>git remote -v</code> — Shows remote repository (should be: origin https://git_to_be_determined).
* <code>git checkout filename</code> — Reverts 'filename' to repository version.
* <code>git stash</code> — Move changes in directory out of the way (in order to 'pull' in changes).
* <code>git stash pop</code> — Restore changes stashed by 'git stash'.
* <code>git diff xxxxx yyyyy</code> — Difference between xxxxx and yyyyy.
* <code>git diff HEAD^</code> — Examine last commit.
* <code>git diff HEAD^^ HEAD^</code> — Examine second to last commit.

== Cheat sheet for Bazaar users ==

{| class="wikitable"
!Bazaar command
!Git command
|-
| class="mw-code" |bzr branch ''branch-url''
| class="mw-code" |git clone ''repository-url'' ''directory'' cd ''directory'' git checkout ''branch-name''
|-
| class="mw-code" |bzr checkout lp:project-name
| not supported
|-
| class="mw-code" |bzr update
| not supported
|-
| class="mw-code" |bzr pull
| class="mw-code" |git pull
|-
| class="mw-code" |bzr add ''file''
| class="mw-code" |git add ''file''
|-
| class="mw-code" |bzr diff
| class="mw-code" |git diff HEAD
|-
| class="mw-code" |bzr revert
| class="mw-code" |git reset --hard
|-
| class="mw-code" |bzr revert ''file'' -r ''revision''
| class="mw-code" |git checkout ''commit'' -- ''file''
|-
| class="mw-code" |bzr uncommit
| class="mw-code" |git reset HEAD^
|-
| class="mw-code" |bzr uncommit ...some changes... bzr commit --local
| class="mw-code" |...some changes... git commit -a --amend
|-
| class="mw-code" |bzr push ''location''
| class="mw-code" |git remote add ''remote-name'' ''location'' git push ''remote-name'' ''branch-name''
|-
| class="mw-code" |bzr commit --local
| class="mw-code" |git commit -a
|-
| class="mw-code" |bzr commit
| class="mw-code" |git commit -a git push
|-
| class="mw-code" |bzr log -c 10
| class="mw-code" |git log -n 10
|-
| class="mw-code" |bzr switch ''branch-url''
| class="mw-code" |git checkout ''branch-name''
|-
| class="mw-code" |bzr switch -b ''branch-url''
| class="mw-code" |git checkout -b ''branch-name''
|-
| class="mw-code" |bzr merge ''branch-url''
| class="mw-code" |git merge ''branch-name''
|-
| class="mw-code" |bzr shelve --all
| class="mw-code" |git stash
|-
| class="mw-code" |bzr unshelve ''change-id''
| class="mw-code" |git stash pop
|}

===Other cheatsheets===

* [http://rogerdudler.github.io/git-guide/ git - the simple guide] - short and sweet, enough to get started

==Differences from Bazaar==

Here are the most important differences between Bazaar and Git:
* Bazaar revisions are identified by sequential numbers. Git revisions (called commits in the documentation) are identified by cryptographic hashes which are strings of 40 hexadecimal numbers, though it is possible to also refer to them by a sequential number since the last tag (see <code>git describe</code>).
* Bazaar is branch-oriented, while Git is repository- and commit-oriented. Repositories in Bazaar are storage locations for potentially multiple branches. Repositories in Git are collections of commits, and branches are just pointers to particular commits that are updated after each <code>git commit</code> command. Cloning a Git repository by default retrieves all of its commits and branches.
* In Bazaar, you conceptually submit your work to only one place - the push branch. You can change this place at any time, but Bazaar remembers only one value for you. In Git, you can configure many remote repositories and work with code from multiple sources using a single working tree.
* By default, each branch in Bazaar has a separate working tree, while all branches in the same Git repository share the same working tree. It's possible to make Bazaar work in the latter mode as well, but it's not very well supported.

In Bazaar, if you want to try out someone else's code, you need to create a new checkout of their branch or use <code>bzr switch</code>. In Git, what you do depends on where the code is located.
* If the code to try out is in a branch in the project's main repository, you update the repository (<code>git fetch</code>) and then check out the branch (<code>git checkout origin/branch-to-try-out</code>). This creates a local branch called <code>branch-to-try-out</code>. (You can use a different name as well.)
* If the code is in a different repository, you first add it as a remote repository with <code>git remote add ''remote-name'' ''repository-url''</code>, fetch it with <code>git fetch ''remote-name''</code> and check out the relevant branch with <code>git checkout ''remote-name''/''branch-to-try-out''</code>.

Another difference is that in Git, you cannot directly make changes to remote branches - you must to use <code>git push</code> and <code>git pull</code>. Therefore, the Subversion-like checkout mode known from Bazaar is unsupported.

==Ideas for an efficient workflow==

Here are some ideas on how you can increase your efficiency when working with git and/or achieve a workflow similar to what you were used to with Bazaar

===Download single branches or shallow clones===

By default <code>git clone https://gitlab.com/inkscape/inkscape.git</code> will download all commits from all branches (currently ~ 1.5 GB).

====Single branches====
If you're only interested in a single branch use
git clone --single-branch [--branch <name>]
which downloads only the files and history for the specified branch. Omit <code>--branch</code> to download trunk / master (currently ~ 900 MB).

====Shallow clones (no history)====
If you're not interested in commit history and only want to download the latest files use
git clone --depth 1 [--branch <name>]
which downloads only the latest revision of the specified branch. Omit <code>--branch</code> to download the latest revision of trunk / master (currently ~ 30 MB).

===Checkout multiple branches into different folders===

As git branches are all stored in the same repository you'll only have one "working tree" (the set of files making up the branch) in the beginning and switching to another branch will modify all files on disk. To have multiple branches (say trunk and 0.92.x) checked out at the same time you can obviously clone the repository multiple times. However it's much more elegant to use the [https://git-scm.com/docs/git-worktree git-worktree] command which links a new working tree to your repository that can be on any branch you want. For example
git worktree add 0.92.x_files 0.92.x
will create a working tree for the ''0.92.x'' branch in the folder ''"0.92.x_files"''. You can then use this new working tree exactly like you'd use the main working tree. (You'll need to run <code>git checkout 0.92.x</code> to set the branch.)

===Use ccache to speed up compilation after switching branches===

As git [https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F does not preserve file modification times] you'd have to do a lot of recompiling whenever switching branches (unless you use the method [[#Checkout multiple branches into different folders|described above]] for all your branches). This can be avoided by using [https://ccache.samba.org/ ccache]. There are many ways to use ccache (search the Internet!). A convenient way when using CMake are the [https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_LAUNCHER.html#variable:CMAKE_%3CLANG%3E_COMPILER_LAUNCHER <code>CMAKE_<LANG>_COMPILER_LAUNCHER</code>] variables (needs CMake 3.4 or later).

Just run CMake with the additional arguments <code>-DCMAKE_C_COMPILER_LAUNCHER="ccache" -DCMAKE_CXX_COMPILER_LAUNCHER="ccache"</code> or use any other way you prefer to set the two variables accordingly.

Compiling Inkscape on Windows with MSYS2

2018-09-10T09:24:56Z

Jnweiger: update --recursive to --recurse-submodules

This page explains how to compile Inkscape on Windows using [http://www.msys2.org/ '''MSYS2'''].

MSYS2 does not only offer a convenient build environment for compiling Inkscape but also provides all necessary build tools and dependencies making it extremely simple to get started with Inkscape development.

== Installing MSYS2 ==

To set-up MSYS2 and download the necessary dependencies only two steps are required:
* '''Step 1''' — Install MSYS2
** Download the installer from the [http://www.msys2.org/ MSYS2 homepage]. Start the installation and follow the instructions on screen.
**After installation finished start an MSYS2 MSYS shell (you can work with the one launched by the installer, use the "MSYS2 MSYS" shortcut in the start menu or launch "msys2.exe" in the installation directory).
**Execute the command <code>pacman -Syu</code>. This will start a full system upgrade and ensure that you have the latest versions of all core libraries (repeat this step until no new updates are found).
* '''Step 2''' — Download dependencies
** Start an MSYS2 MinGW shell (use the "MSYS2 MinGW 32/64-bit" shortcut in the start menu or launch "mingw32/64.exe" in the installation directory). Choose the shell in this step (32-bit or 64-bit) according to whether you want to build a 32-bit or 64-bit version of Inkscape later.
** Execute the script [https://gitlab.com/inkscape/inkscape/blob/master/buildtools/msys2installdeps.sh msys2installdeps.sh] by either copy-and-pasting it into the console or by downloading it and (after changing to the folder containing the file) typing <code>./msys2installdeps.sh</code>. If you already have a copy of the Inkscape source it should also be included in the "buildtools" folder.
Step 2 will take some time to complete (approx. 10 minutes depending on the speed of your internet connection and the load of the download servers), so relax and get a cup of coffee...

== Obtaining Inkscape Source ==

''Note: For general instructions on how to use Git see [[Working with Git]].''

As MSYS2 provides the revision control software Git you do not need to download it separately. Simply open the MSYS2 MinGW shell and run the command
<pre>git clone --recurse-submodules https://gitlab.com/inkscape/inkscape.git master</pre>
This creates a folder called "master" in the current working directory (usually the home folder located at "C:\msys64\home\Your_Username" or similar) in which the clone of the source repository is created.

You can later update it with:
<pre>
git pull --recurse-submodules
</pre>

== Building Inkscape with MSYS2 ==

To compile Inkscape open the MSYS2 MinGW shell (remember to use the correct shell, i.e. 32-bit or 64-bit, matching the dependencies you downloaded above and the version of Inkscape you want to build).

Then execute the following commands:
<pre>
# change to the directory containing your Inkscape source checkout (has to be adjusted to match your system)
cd master

# create a directory for the build (could also be another folder, but we'll assume 'build' being used for the rest of the article)
mkdir build
cd build

# create build files with CMake (we generate rules for "Ninja" as it's significantly faster then "MinGW Makefiles" which uses mingw32-make)
# note the source path '..' (which in this case is the parent directory) and should always point to the root folder of your copy of the Inkscape source
cmake -G Ninja ..

# start the compilation
ninja

# install compiled files and all dependencies required to run Inkscape into the folder 'build/inkscape/'
ninja install

# The last two steps can be combined (i.e. run 'ninja install' immediately) if you want to save time in future, as the "install" target also includes the default target
</pre>

'''''That's it!''''' 
Afterwards you should have a complete binary distribution of Inkscape in the folder "build/inkscape/" that can be run on <abbr title="Please note that GTK+3 (the toolkit used for creating Inkscape's UI) has dropped support for Windows XP, so builds of master will only run on Windows Vista and later. Windows XP is still supported in the 0.92.x branch, though.">any Windows machine</abbr>.

== Packaging ==

If you only want to run Inkscape you do ''not'' need to follow these instructions. Simply execute <code>inkscape.exe</code> from the "build/inkscape/" directory created in the previous step, the <code>ninja install</code> command takes care of copying all required files into this directory.

To package those files for distribution (this should only concern package maintainers or people who want to improve the installer code) we offer a set of CMake convenience targets that can be executed as follows:
* <code>ninja dist-win-7z</code> – generate binary 7z archive. You'll need to install [http://www.7-zip.org/ 7-Zip].
* <code>ninja dist-win-exe</code> – generate .exe installer. You'll need to install [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)] version 3 or later.
* <code>ninja dist-win-msi</code> – generate .msi installer. You'll need to install [http://wixtoolset.org/ Windows Installer XML (WiX Toolset)].
* Additionally there's a <code>dist-win-all</code> target (executes all of the above in parallel) and for each of the three there's also a <code>dist-win-*-fast</code> target (which is identical in functionality but will use a faster compression method which will increase package size but will also significantly reduce packaging time which can be useful for debugging/development purposes).

For some additional details which have not been incorporated into this page yet see the previous instructions at [[Compiling Inkscape on Windows 32-bit#Creating an installer]] (might be partially oudated).

Compiling Inkscape on Windows with MSYS2

2018-09-09T21:27:56Z

Jnweiger: added --recursive

This page explains how to compile Inkscape on Windows using [http://www.msys2.org/ '''MSYS2'''].

MSYS2 does not only offer a convenient build environment for compiling Inkscape but also provides all necessary build tools and dependencies making it extremely simple to get started with Inkscape development.

== Installing MSYS2 ==

To set-up MSYS2 and download the necessary dependencies only two steps are required:
* '''Step 1''' — Install MSYS2
** Download the installer from the [http://www.msys2.org/ MSYS2 homepage]. Start the installation and follow the instructions on screen.
**After installation finished start an MSYS2 MSYS shell (you can work with the one launched by the installer, use the "MSYS2 MSYS" shortcut in the start menu or launch "msys2.exe" in the installation directory).
**Execute the command <code>pacman -Syu</code>. This will start a full system upgrade and ensure that you have the latest versions of all core libraries (repeat this step until no new updates are found).
* '''Step 2''' — Download dependencies
** Start an MSYS2 MinGW shell (use the "MSYS2 MinGW 32/64-bit" shortcut in the start menu or launch "mingw32/64.exe" in the installation directory). Choose the shell in this step (32-bit or 64-bit) according to whether you want to build a 32-bit or 64-bit version of Inkscape later.
** Execute the script [https://gitlab.com/inkscape/inkscape/blob/master/buildtools/msys2installdeps.sh msys2installdeps.sh] by either copy-and-pasting it into the console or by downloading it and (after changing to the folder containing the file) typing <code>./msys2installdeps.sh</code>. If you already have a copy of the Inkscape source it should also be included in the "buildtools" folder.
Step 2 will take some time to complete (approx. 10 minutes depending on the speed of your internet connection and the load of the download servers), so relax and get a cup of coffee...

== Obtaining Inkscape Source ==

''Note: For general instructions on how to use Git see [[Working with Git]].''

As MSYS2 provides the revision control software Git you do not need to download it separately. Simply open the MSYS2 MinGW shell and run the command
<pre>git clone --recursive https://gitlab.com/inkscape/inkscape.git master</pre>
This creates a folder called "master" in the current working directory (usually the home folder located at "C:\msys64\home\Your_Username" or similar) in which the so-called clone of the source repository is created.

== Building Inkscape with MSYS2 ==

To compile Inkscape open the MSYS2 MinGW shell (remember to use the correct shell, i.e. 32-bit or 64-bit, matching the dependencies you downloaded above and the version of Inkscape you want to build).

Then execute the following commands:
<pre>
# change to the directory containing your Inkscape source checkout (has to be adjusted to match your system)
cd master

# create a directory for the build (could also be another folder, but we'll assume 'build' being used for the rest of the article)
mkdir build
cd build

# create build files with CMake (we generate rules for "Ninja" as it's significantly faster then "MinGW Makefiles" which uses mingw32-make)
# note the source path '..' (which in this case is the parent directory) and should always point to the root folder of your copy of the Inkscape source
cmake -G Ninja ..

# start the compilation
ninja

# install compiled files and all dependencies required to run Inkscape into the folder 'build/inkscape/'
ninja install

# The last two steps can be combined (i.e. run 'ninja install' immediately) if you want to save time in future, as the "install" target also includes the default target
</pre>

'''''That's it!''''' 
Afterwards you should have a complete binary distribution of Inkscape in the folder "build/inkscape/" that can be run on <abbr title="Please note that GTK+3 (the toolkit used for creating Inkscape's UI) has dropped support for Windows XP, so builds of master will only run on Windows Vista and later. Windows XP is still supported in the 0.92.x branch, though.">any Windows machine</abbr>.

== Packaging ==

If you only want to run Inkscape you do ''not'' need to follow these instructions. Simply execute <code>inkscape.exe</code> from the "build/inkscape/" directory created in the previous step, the <code>ninja install</code> command takes care of copying all required files into this directory.

To package those files for distribution (this should only concern package maintainers or people who want to improve the installer code) we offer a set of CMake convenience targets that can be executed as follows:
* <code>ninja dist-win-7z</code> – generate binary 7z archive. You'll need to install [http://www.7-zip.org/ 7-Zip].
* <code>ninja dist-win-exe</code> – generate .exe installer. You'll need to install [http://nsis.sourceforge.net/ Nullsoft Scriptable Install System (NSIS)] version 3 or later.
* <code>ninja dist-win-msi</code> – generate .msi installer. You'll need to install [http://wixtoolset.org/ Windows Installer XML (WiX Toolset)].
* Additionally there's a <code>dist-win-all</code> target (executes all of the above in parallel) and for each of the three there's also a <code>dist-win-*-fast</code> target (which is identical in functionality but will use a faster compression method which will increase package size but will also significantly reduce packaging time which can be useful for debugging/development purposes).

For some additional details which have not been incorporated into this page yet see the previous instructions at [[Compiling Inkscape on Windows 32-bit#Creating an installer]] (might be partially oudated).

2018-06-20T16:29:15Z

Jnweiger: .

Other pages: [[Hackfest2018 Kiel]], [[Hackfest2018 Kiel Topics]].

== Who is Attending? ==

{| class="wikitable" style="text-align: center;"
|+ List of Attendees
Hackfest
|-
! rowspan="2" | Who
! rowspan="2" | Dates
! rowspan="2" | Maximum Allocation
! colspan="2" | Arrival
! colspan="2" | Departure
! rowspan="2" | Hotel
|-
! Date/Time
! Detail
! Date/Time
! Detail
|-
| Tavmjong Bah
| 9/9, 9/10, 9/11, 9/12, 9/13 (TBC)
| TBD
|
|
|
|
|
|-
| Maren Hachmann
| 9/9, 9/10, 9/11, 9/12, 9/13
| N/A (local)
|
|
|
|
|
|-
| Martin Owens
| 9/9, 9/10, 9/11, 9/12, 9/13
| TBD
| 2018-09-08
| Iceland Air (FI632)-(FI510)
| 2018-09-14
| Iceland Air (FI511)-(FI633)
| TBC
|-
| Thomas Holder
| 9-? (TBC)
|
|
|
|
|
|
|-
| Christopher Rogers
| 9-13
| TBD
|
|
|
|
|
|-
| Marc Jeanmougin
| 9-13
| TBD
|
|
|
|
|
|-
| Jabier Arraiza
| 9-13
| TBD
|
|
|
|
|
|-
| Mihaela Jurković
| 9-13 (TBC)
| TBD
|
|
|
|
|
|-
| Max Gaukler
| 9-? (TBD)
| TBD (some place to sleep + ca 200$ for travel)
|
|
|
|
|
|-
| Krzysztof Kosiński
| 9/? (TBD)
| $0 (self-sponsored)
|
|
|
|
|
|-
| Patrick "Ede_123" Storz
| 9/? (TBD)
| TBD
|
|
|
|
|
|-
| Jürgeb Weigert
| 9-13
| TBD
|
|
|
|
|
|-
! Total
!
! $xxxx
!
!
!
!
!
|}

TBD: "To Be Determined"

Budget TBD. Separate allocation for Inkscape dinner (TBD). Venue: Free.

''' Funding approved, funding details need to be determined in a second election by Inkscape board.'''

Allocation for attending hackfest:
* TBD

Hackfest2018 Kiel Attendees

2018-06-20T16:28:14Z

Jnweiger: ne too! :-)

Other pages: [[Hackfest2018 Kiel]], [[Hackfest2018 Kiel Topics]].

== Who is Attending? ==

{| class="wikitable" style="text-align: center;"
|+ List of Attendees
Hackfest
|-
! rowspan="2" | Who
! rowspan="2" | Dates
! rowspan="2" | Maximum Allocation
! colspan="2" | Arrival
! colspan="2" | Departure
! rowspan="2" | Hotel
|-
! Date/Time
! Detail
! Date/Time
! Detail
|-
| Tavmjong Bah
| 9/9, 9/10, 9/11, 9/12, 9/13 (TBC)
| TBD
|
|
|
|
|
|-
| Maren Hachmann
| 9/9, 9/10, 9/11, 9/12, 9/13
| N/A (local)
|
|
|
|
|
|-
| Martin Owens
| 9/9, 9/10, 9/11, 9/12, 9/13
| TBD
| 2018-09-08
| Iceland Air (FI632)-(FI510)
| 2018-09-14
| Iceland Air (FI511)-(FI633)
| TBC
|-
| Thomas Holder
| 9-? (TBC)
|
|
|
|
|
|
|-
| Christopher Rogers
| 9-13
| TBD
|
|
|
|
|
|-
| Marc Jeanmougin
| 9-13
| TBD
|
|
|
|
|
|-
| Jabier Arraiza
| 9-13
| TBD
|
|
|
|
|
|-
| Mihaela Jurković
| 9-13 (TBC)
| TBD
|
|
|
|
|
|-
| Max Gaukler
| 9-? (TBD)
| TBD (some place to sleep + ca 200$ for travel)
|
|
|
|
|
|-
| Krzysztof Kosiński
| 9/? (TBD)
| $0 (self-sponsored)
|
|
|
|
|
|-
| Patrick "Ede_123" Storz
| 9/? (TBD)
| TBD
|
|
|
|
||-
| Jürgeb Weigert
| 9-13
| TBD
|
|
|
|
|
|-
! Total
!
! $xxxx
!
!
!
!
!
|}

TBD: "To Be Determined"

Budget TBD. Separate allocation for Inkscape dinner (TBD). Venue: Free.

''' Funding approved, funding details need to be determined in a second election by Inkscape board.'''

Allocation for attending hackfest:
* TBD