Inkscape Wiki - User contributions [en]

User:Shlomif

2017-03-26T07:17:00Z

Shlomif: Add some rudimentary info and links.

My name is Shlomi Fish. Here are some links for more information about me:

* [http://www.shlomifish.org/ Shlomi Fish's Homepage]
* [http://en.wikipedia.org/wiki/User:Shlomif User page on the English wikipedia] - with links to user pages on other wikis.
* [http://www.shlomifish.org/me/contact-me/ Contact Information]

How to start a page

2017-03-26T07:09:25Z

Shlomif: add the info about the account creation.

{{Other languages|en=How to start a page}}

First of all note that you need to have an Inkscape Wiki account opened for you. To do so, post an E-mail message to the [https://inkscape.org/en/community/mailing-lists/#inkscape-devel inkscape-devel mailing list] requesting such an account.

There are two basic ways to start a Wiki page:
#As you're reading through already-existing articles, you'll see question marks that are clickable links. You can click on a "?" link that appears after an article title, and you'll arrive at a page that says "Describe the new page here." Just delete that text and replace it with the text of your article. When you're finished, click the "Save" button at the bottom of the page. (Use the "[[Preview]]" button if you want to see what the page will look like first.) -- Modifying arbitrary pages by adding/wikifying a new term and then adding a well-written entry linked from that page are a great way to continually add new topics to the site.
#If you want to create a brand-new topic, probably the first thing to do is to use the "search" form (see the bottom of this page, for example) and see whether someone has not already created some very similar page. If not, you can find some related topic, edit ''that'' page, and (in an appropriate place) add the title of the article you want to create between double brackets, <nowiki>[[like this]]</nowiki>. Then press the "save" button at the bottom of the page. On the page you just edited, you should see a clickable "?"; click on that and go to work on your new page! --
Some thoughts:
* This is a '''MediaWiki wiki''' — it allows use of spaces in wikilinks, so '''use of CamelCase to create links is not needed or desirable'''. New article (page) titles should use sentence-case, i.e., capitalise the first word in the title and leave the rest lowercase, unless certain words in the title are proper nouns. Wikilinks in articles are created by enclosing a word or set of words with '''<nowiki>[[nested brackets]]</nowiki>'''. If you find a wikilink to a non-existent article that uses CamelCase run-together text, correct the link in that article according to these conventions before creating the new target article.
* If you like, you can enter just a line or two of text for an entry. It's a start. Full-blown articles are not required. Adding any (accurate, helpful) information is welcome! Of course, if you can write more, that's all the better; some people do, as a matter of habit, usually write more than just a few lines when they start a new article.
* How you word your articles will determine, to some extent, how likely it is other people will work on it. Examples:
**An article that leaves many intriguing-sounding links or leaves ellipses (...), etc., might invite other know-it-alls to fill in the blanks.
**Straightforward requests for information in an article can lead to good articles. For example, one might supply a rough description of a thing or place and then ask about its history; some people who know the answer will find it difficult to pass up the opportunity to teach.

----
This article is an edited version of one by the same name from [http://www.wikipedia.com Wikipedia.com], reusable under the terms of the [http://www.gnu.org/copyleft/fdl.html GNU Free Documentation License].

[[Category:User Documentation]]

AnnouncePlanning092

2017-01-03T20:42:04Z

Shlomif: Fixed tense.

TODO:
* (DONE) Merge in AnnouncePlanning091 as template
* (DONE) Copyedit this page to change 0.91 to 0.92
* Copyedit this page to trim out stuff that doesn't need done, and add todo's where appropriate
* (DONE) Add need for screenshots, graphics, etc.
* (DONE) List pages in the site that will need updating: News entry, Downloads, Screenshots, ...
* Add more news sites to notify
* Add a Slashdot Blurb, using the 0.91 (or 0.47) posting as a starting point
* Perform the tasks listed below

This announce planning page is based on [[AnnouncePlanning047]] - What you see below has been copied from there and edited. Refer to the [[Release notes/0.92]] for details on what's new, different and improved.

== Tasks ==
{| class="wikitable"
|-
! Task || Performer ||Projected Date of completion || Status
|-
| colspan="4"| '''Write PR texts'''
|- style="background:#eeeeee;"
| Informal PR text - DRAFT
|
|
| 0%
|- style="background:#eeeeee;"
| Informal PR text
|
|
| 0%
|- style="background:#eeeeee;"
| Translated Informal PR text
|
|
| 0%
|- style="background:#dddddd;"
| Formal PR text - DRAFT
|
|
| 0%
|- style="background:#eeeeee;"
| Make 2 or 3 official screenshots that demonstrate new features. Use as attachments for formal PR texts - if not done: use new [https://inkscape.org/~artelnjeru01/%E2%98%85about-092-2-good About Screen ], [http://www.inkscapeforum.com/viewtopic.php?f=21&t=31053 here] are a couple of images that could be used).
|
|
| 0%
|- style="background:#dddddd;"
| Formal PR text
|
|
| 0%
|- style="background:#dddddd;"
| Translate Formal PR text
|
|
| 0%
|-
| colspan="4"| '''Spread PR'''
|-
| Update and add new Contacts & Sources on this Wiki page
|
|
| 0%
|-
| Contact Contacts & Sources on this Wiki page
| See below for people who will contact news sites, lists etc.
|
| 0%
|-
| colspan="4"| '''Update website'''
|- style="background:#eeeeee;"
| Add News article to Inkscape website
|
|
| 0%
|- style="background:#eeeeee;"
| Update all pages in Downloads menu (also add a special note to the OS X downloads page about unavailability of 0.92, and how to contribute)
| Uploaders, Maren
|
| 0%
|- style="background:#eeeeee;"
| Update The Next Release Page
|
|
| 0%
|- style="background:#eeeeee;"
| Review FAQ and add important items (units conversion, dialogs minimized bug, font manager bug, missing OS X version)
|
|
| 0%
|- style="background:#eeeeee;"
| Add screenshot with mesh gradient to screenshots page
|
|
| 0%
|- style="background:#eeeeee;"
| Update docs repository to show docs for 0.92 per default
| jazzynico
|
| 0%
|- style="background:#eeeeee;"
| Update Learn -> Books to link to new keyboard shortcut list
| Maren
|
| 0%
|- style="background:#eeeeee;"
| Optional: review Features page and add a couple of new ones.
|
|
| 0%
|- style="background:#eeeeee;"
| Translate website changes (needs not be complete for release, priority: news, downloads pages)
| Website translators
|
| 0%
|- style="background:#eeeeee;"
| Unpublish outdated downloads pages for orphaned languages
| Maren
|
| 0%
|- style="background:#eeeeee;"
| Update images in the front shield
|
|
| 0%
|- style="background:#eeeeee;"
| Add current release into the releases db
| Maren
|
| 0%
|}

=Announcement Process=
# Create News posts (using the small overview below) on all the relevant social sites: reddit, twitter, facebook, Google+, hacker news, slashdot, etc.
# Create a new Page on the Inkscape website that has the Formal Announcement on it (for linking purposes) have links back to the social bookmarking stories for the release.
# Post the official announcement to the Inkscape News on the website, and on all the relevant Inkscape lists (eg. announce, user, developer)
# Send out the informal announcement (include a link to the web page with the formal announcement)
# Send out the formal announcement. (include a link to the web page with the formal announcement)

=Press Release Translations=
Once the English Press Release text has been finalized, translation can start into other languages.

The current goal for this PR text is to have the English version finished by [DATE TO BE DETERMINED].

Please Create a new Wiki page for planning / translating the 0.92 PR in your language here:
* [[Inkscape092-PRannounce-fr]]
* [[Inkscape092-PRannounce-de]]
* [[Inkscape092-PRannounce-es]]
* [[Inkscape092-PRannounce-pt]]
* [[Inkscape092-PRannounce-zh]]
etc...

=Press Release Text=
== Brief Overview ==
The Inkscape project announces a new version 0.92 of its popular vector drawing software. This release adds mesh gradients, improves SVG2 and CSS3 support, new path effects, and a whole host of other features, updates, and bug fixes. Inkscape is free, open source software available to everyone in the world.

Details: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92

Screenshots: http://inkscape.org/screenshots/

Download: http://inkscape.org/download/



== Informal Announcement Text ==

Inkscape Version 0.92 is Released!

The Inkscape project announces a new version 0.92 of its popular vector drawing software. New features include mesh gradients, improved SVG2 and CSS3 support, new path effects, interactive smoothing for the pencil tool, a new Object dialog for directly managing all drawing elements, and much more. Infrastructural changes are also under way, including a switch to CMake from the venerable Autotools build system.

Mesh gradients are a powerful tool enabling artists to more easily create photo-realistic drawings - a feature we would love to see made part of the W3C's Scalable Vector Graphics (SVG) standard; if you find this feature as cool as we do, please request that your favorite web browser adopts support for it too! Inkscape works closely with the SVG standards committee, and thanks to our many generous donors the Inkscape project sponsors an engineering representative to attend SVG working group meetings over the past few years; a welcome outcome of this participation is the improvement and addition of over a dozen SVG and CSS properties, such as paint-order, white-space, and mix-blend-mode.

Live Path Effects are proving to be a vibrant ecosystem in the Inkscape project, and many innovative new ideas have been percolating over the past couple years since our last release. Spiro Live, BSpline, and Roughen essentially provide new drawing modes. The Simplify LPE cleans up vector elements non-destructively by smoothing paths, shapes, groups, clips, and masks. Perspective/Envelope and Lattice Deformation 2 enable artists to interactively deform/transform drawing elements. Other new features enable interactive mirroring, interactive rotation of copies along an arc or circle, and dozens of other additions and enhancements.

All software must evolve with the times, and Inkscape is no different. To maintain consistency with the CSS standard, Inkscape's default resolution has changed from 90dpi to 96dpi; Inkscape will detect files created with previous versions and offer to convert them. A number of infrastructural changes are in process to help Inkscape keep up with progress. For 0.92 we are changing to the CMake build system, which builds faster and is easier for developers to work with. (Future infrastructure changes include switching from bzr to git, shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)

The above barely scratches the surface of all the new stuff included in this release. For the full story, including examples, screenshots, and videos, please see our detailed Release Notes:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92

Installation packages are available for Linux and Windows. If you're on Linux, you'll soon be able to install it from your distribution via normal methods. If on Windows, we have a set of packages that we hope will let you maximize performance on your platform. For Mac OS X, no packages are available -- our old (X11/XQuartz) packaging was long overdue to be updated to current standards and is no longer being maintained.

The Inkscape Project thrives due to your support. We are a volunteer-driven community build from thousands of contributions of time, skill, and funds, to create a powerful open source tool that is made available for free to everyone in the world. We invite you to join our community and participate in helping advance Inkscape towards new objectives. Come help us chart out the new directions that Inkscape needs to take. Inkscape is created *by* the community *for* the community.

Your donations also help further Inkscape's mission. You can donate to Inkscape's general fund, or target your donation to support our SVG Standards work or Hackfests.

Join Inkscape at: https://inkscape.org/en/community/
Become a donor at: https://inkscape.org/en/support-us/
Download Inkscape at: https://inkscape.org/download/

== Formal Announcement Text ==

==== The Inkscape Community Releases Inkscape 0.92 ====

New York, NY, [RELEASE DATE] -- The Inkscape community announces the release of Inkscape 0.92. Inkscape is a multi-platform, Open-Source Vector Graphics Editor that uses SVG as its native file format. Digital artists use it to produce professional quality work. Engineers and scientists use it to create clear drawings to explain their ideas. Everyday people use it to create simple drawings, develop their design skills, and just have fun. This new version features ...[INSERT MAIN FEATURES HERE].

This newest Inkscape release includes a wealth of new tools and improvements developed over the past year, [SHORTENED RELEASE CYCLE :)].

[NEW FEATURES IN DETAIL WITH A COOL USAGE EXAMPLE GO HERE]

[MUCH OF THE WORK HAS BEEN IN THE BACKGROUND, TO SET INKSCAPE DEVELOPMENT UP FOR THE FUTURE (C++11, CMAKE)]

With 0.92 out the door, the Inkscape community is already working on the upcoming 0.92, which [RELEASE FOCUS]. Future releases will focus on stabilization in preparation for a 1.0 version release.

For a complete list of new and improved features see the 0.92 Release Notes: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.92

[PLANS FOR A HACKFEST, MAYBE? CALL FOR GENERAL DONATIONS, HELP SPREADING MESH USAGE, PROJECT PARTICIPATION, BUYING IN THE SHOP? HELP PROVIDING AN OS X VERSION]

The new version of Inkscape for Windows and Linux can be obtained from Inkscape's download page: https://inkscape.org/download/.

==== About Inkscape ====

Inkscape is an open source drawing tool that uses the World Wide Web Consortium's (W3C) scalable vector graphics format (SVG). Some supported SVG features include basic shapes, paths, text, markers, clones, alpha blending, transforms, gradients, and grouping. In addition, Inkscape supports Creative Commons' metadata, node-editing, layers, complex path operations, text-on-path, text-in-shape, and SVG XML editing. It can also import EPS, PostScript, and most bitmap formats, and exports PNG, PS, PDF and various vector formats. Inkscape's main motivation is to provide the Open Source community with a fully W3C compliant XML, SVG, and CSS3 drawing tool. Additional work includes conversion of the codebase from C/Gtk to C++/Gtkmm, emphasizing a lightweight core with powerful features added through an extension mechanism, and maintaining a friendly, open, community-oriented development process.

=Places to Announce=
== Receive small overview==
{|style="background:#f2f2f2;"
!style="text-align:left;background-color:#d3d7cf;width:20%;"|Web Site / Media
!style="text-align:left;background-color:#d3d7cf;width:30%;"|Who will contact / post
!style="text-align:left;background-color:#d3d7cf;width:50%;"|Notes...
|-style="border-bottom:white 2px solid;"
|http://reddit.com
|?
|someone needs to post a short excerpt announcing the release, and link it to inkscape.org.
|-style="border-bottom:white 2px solid;"
|http://digg.com
|?
|someone needs to post a short excerpt announcing the release, and link it to inkscape.org.
|-style="border-bottom:white 2px solid;"
|http://slashdot.org
|?
|submit a new news item.
|-style="border-bottom:white 2px solid;"
|http://newsvine.com
|?
|submit a new news item.
|-style="border-bottom:white 2px solid;"
|1
|2
|3
|-style="border-bottom:white 2px solid;"
|(1 Web Site / Media)
|(2 Who will contact / post) ~ '''done'''
|(3 Notes...)
|-style="border-bottom:white 2px solid;"
|}

== Receive Informal PR ==
=== Open Source Community ===
{| style="background:#f2f2f2;"
!style="text-align:left;background-color:#d3d7cf;width:20%;"|Contact Name
!style="text-align:left;background-color:#d3d7cf;width:30%;"|Who will contact / post
!style="text-align:left;background-color:#d3d7cf;width:50%;"|Notes...
|- style="border-bottom:white 2px solid;"
|gnome office list
|?
|gnome-office-list at gnome dot org
|-style="border-bottom:white 2px solid;"
|svg developers yahoo group
|?
|svg-developers at yahoo dot com must join the list to send (rejon is on)
|-style="border-bottom:white 2px solid;"
|cairo list
|bryce
|cairo at cairographics dot org
|-style="border-bottom:white 2px solid;"
|gnome-list
|bryce
|gnome-announce-list at gnome dot org
|-style="border-bottom:white 2px solid;"
|Scribus Lists
|bryce
|see http://lists.scribus.net/mailman/listinfo/scribus-dev and http://lists.scribus.net/mailman/listinfo/scribus
|-style="border-bottom:white 2px solid;"
|osnews.com
|bryce
|http://osnews.com/submit.php
|-style="border-bottom:white 2px solid;"
|scale-a-vector
|bryce
|kukofka at scale-a-vector dot de http://www.scale-a-vector.de/cont.htm
|-style="border-bottom:white 2px solid;"
|http://dot.kde.org
|
|http://dot.kde.org/addPostingForm
|-style="border-bottom:white 2px solid;"
|phoronix.com
|bryce
|news@phoronix.com
|-style="border-bottom:white 2px solid;"
|}

=== Broader Inkscape & Art Community ===
{|style="background:#f2f2f2;"
!style="text-align:left;background-color:#d3d7cf;width:20%;"|Contact Name
!style="text-align:left;background-color:#d3d7cf;width:30%;"|Who will contact / post?
!style="text-align:left;background-color:#d3d7cf;width:50%;"|Notes...
|-style="border-bottom:white 2px solid;"
|Inkscape deviantart group
|ScislaC?
|http://inkscape.deviantart.com/
|
|-style="border-bottom:white 2px solid;"
|the inkscape forum
|ScislaC / Brynn?
|http://www.inkscapeforum.com/ run by microUgly
|-style="border-bottom:white 2px solid;"
|inkscape tutorials blog
|ryan lerch?
|http://inkscapetutorials.wordpress.com/
|-
|-style="border-bottom:white 2px solid;"
|open clip art library list
|
|clipart@freedesktop.org
|-style="border-bottom:white 2px solid;"
|open clip art library news
|
|
|-style="border-bottom:white 2px solid;"
|Inkscape Community (tutorials, forum, gallery)
|brynn
|http://forum.inkscapecommunity.com/index.php
|-style="border-bottom:white 2px solid;"
|artdc.org forum
|
|http://www.artdc.org/
|-style="border-bottom:white 2px solid;"
|bittbox.com - vector art blog
|bryce
|contact(at)bittbox.com
|-style="border-bottom:white 2px solid;"
|The Daily Ubuntu - Daily Ubuntu Applications
|bryce
|http://www.contactify.com/35b54
|-style="border-bottom:white 2px solid;"
|Google+ Inkscape
|Tav?
|https://plus.google.com/u/0/b/108911244660285152681/+inkscape/posts
|-style="border-bottom:white 2px solid;"
|Twitter Inkscape
|Scislac?
|https://twitter.com/inkscape
|-style="border-bottom:white 2px solid;"
|Facebook Inkscape
|Scislac?
|https://facebook.com/Inkscape.org/
|}

=== Other Inkscape Users ===
Inkscape is attracting growing numbers of users in different fields such as scrapbooking, craft-makers, fabric designers and people creating a range of technical drawings. How can we get the word out to these groups?

{|style="background:#f2f2f2;"
!style="text-align:left;background-color:#d3d7cf;width:30%;"|website / magazine / list
!style="text-align:left;background-color:#d3d7cf;width:20%;"|Who will contact / post?
!style="text-align:left;background-color:#d3d7cf;width:50%;"|Notes...
|-style="border-bottom:white 2px solid;"
|http://www.inkscapecuttingdesign.com/smf/
|Brynn?
|
|-style="border-bottom:white 2px solid;"
|http://forum.inkscapecommunity.com/index.php
|Brynn?
|
|-style="border-bottom:white 2px solid;"
|http://inkscape-forum.de/
|Maren
|
|-style="border-bottom:white 2px solid;"
|
|
|
|-
|}

== Receive Formal PR ==
{|style="background:#f2f2f2;"
!style="text-align:left;background-color:#d3d7cf;width:20%;"|Contact Name
!style="text-align:left;background-color:#d3d7cf;width:30%;"|Who will contact / post?
!style="text-align:left;background-color:#d3d7cf;width:50%;"|Notes...
|-style="border-bottom:white 2px solid;"
|http://linuxformat.co.uk/
|?
|login and submit news via top of page link
|-style="border-bottom:white 2px solid;"
|http://linux-magazine.com/
|bryce
|pr(at)linux - magazine (dot) com
|-style="border-bottom:white 2px solid;"
|http://linuxmagazine.com/
|?
|jbrockmeier at linux hyphen mag DOT com.
|-style="border-bottom:white 2px solid;"
|http://cmykmag.com/
|?
|
|-style="border-bottom:white 2px solid;"
|http://lwn.net
|bryce
|pr@lwn.net
|-style="border-bottom:white 2px solid;"
|
|
|
|-
|}

=== Other ===

* Smashing Magazine - http://www.smashingmagazine.com/
* [http://openpr.com openpr] - http://openpr.com/news/submit.html
* nettime-ann - http://www.nettime.org/
* See Kansas City infoZine: http://www.infozine.com/news/stories/op/storiesView/sid/5080/
* http://graphicdesign.about.com
* http://graphicssoft.about.com
* http://desktoppublishing.about.com

=== German news sites ===

Release Notes are available in German:
[[Release_notes/0.92/de]]

These will be contacted by ? 

* [http://it-news-blog.org http://it-news-blog.org] contact@manuelziegler.de
* [http://ubuntunews.de/ http://ubuntunews.de/] impressum@picomol.de
* [http://winfuture.de/ http://winfuture.de/] Presse@WinFuture.de
* [http://www.chip.de/ http://www.chip.de/] info@chip.de
* [http://www.com-magazin.de/ http://www.com-magazin.de/] redaktion@com-magazin.de
* [http://www.dpa.de/ http://www.dpa.de/] presse@dpa.com
* [http://www.faz.net/ http://www.faz.net/] Info@faz.net
* http://www.geektown.de vs.impressum@googlemail.com
* [http://www.golem.de/sonstiges/impressum.html http://www.golem.de/sonstiges/impressum.html], press@golem.de
* [http://www.gulli.com http://www.gulli.com] news@gulli.com
* [http://www.heise.de/kontakt/ http://www.heise.de/kontakt/]
* [http://www.itespresso.de/ http://www.itespresso.de/] redaktion@netmediaeurope.com
* [http://www.it-times.de/kontakt/ http://www.it-times.de/kontakt/]
* [http://www.linux-community.de/ http://www.linux-community.de/] redaktion@linux-community.de
* [http://www.linux-magazin.de/ http://www.linux-magazin.de/] redaktion@linux-magazin.de
* [http://www.netzwelt.de/ http://www.netzwelt.de/] info@netzwelt.de
* [http://www.pc-magazin.de/ http://www.pc-magazin.de/] redaktion@pc-magazin.de
* [http://www.pcwelt.de/ http://www.pcwelt.de/] pressemitteilung@pcwelt.de
* [http://www.pro-linux.de/news/10/1/news-mitteilen.html http://www.pro-linux.de/news/10/1/news-mitteilen.html] (nur reinkopieren ins Formular) und
* [http://www.t-online.de/ http://www.t-online.de/] impressum@telekom.de
* [http://www.zdnet.de/ http://www.zdnet.de/] de-presse@netmediaeurope.com

=== French websites ===

These will be contacted by ? :

* [http://www.linuxgraphic.org/wp/ http://www.linuxgraphic.org/wp/], [http://www.linuxgraphic.org/wp/proposition-darticle/]
* [http://afgral.org/ http://afgral.org/], contact.afgral@gmail...
* [http://linuxfr.org/ http://linuxfr.org/]
* [http://www.01net.com/ http://www.01net.com/]
* [http://www.linformaticien.com/ http://www.linformaticien.com/]
* [http://www.clubic.com/ http://www.clubic.com/]
* [http://korben.info/ http://korben.info/]
* [http://owni.fr/ http://owni.fr/]
* [http://www.zdnet.fr/ http://www.zdnet.fr/]
* [https://framasoft.org/ framasoft]

=== Reactions ===

==== en ====
* ...

==== de ====
* ...

==== fr ====
* ...

Compiling Inkscape on Windows 32-bit

2016-06-07T07:13:55Z

Shlomif: Correct some typos - thanks to mathog

'''For 64 bit: see [[Compiling Inkscape on Windows 64-bit]]'''

----

Inkscape was originally written for Linux, but it has been ported to other platforms, including Windows. Since Windows is not POSIX compliant and doesn't have several features useful to developers (like package management), compiling Inkscape on Windows is more tedious than on Linux, but perfectly possible. To make it easier, we have compiled a package that contains all the libraries you need to build Inkscape. This reduces the effort of compiling Inkscape to: download and install 3 programs, download library package, download sourcecode, and you are ready to go.

==Setting up the build environment==

To develop Inkscape, you will need the following things:

* [http://wiki.bazaar.canonical.com/WindowsDownloads Bazaar]
* [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] programs: puttygen.exe and pageant.exe
* TDM's GCC (MingW): Please use exactly the [http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/tdm-gcc-4.6.1.exe/download version 4.6.1 32bit bundle installer] and follow the instructions below. In the setup, '''Uncheck''' the [''Check for updated files on the TDM-GCC server''] when installing, or it will install a newer version. Newer versions (tdm-gcc-4.7+) introduce important changes in gcc and don't work with the current Inkscape devlibs (see the [http://old.nabble.com/Compiling-on-Windows-7-x64-td34601489.html discussion on the developers' list]).
* Launchpad account

In order to build the installer (not needed for most developers):
* [http://wixtoolset.org Windows Installer XML Toolset] for rencent msi builds
* [http://sourceforge.net/projects/nsis/files/NSIS%202/2.46/nsis-2.46-setup.exe/download NSIS 2.46]

===Install the compiler===
Run the TDM-MinGW installer:
# Install in a path that doesn't contain spaces. The path 'C:\mingw' is ideal beacuse it is currently set in the <tt>mingwenv.bat</tt> file (along with the location of devlibs).
#* TDM-MinGW's default install option may be to a different location. You will have to edit the <tt>mingwenv.bat</tt> file to point there.
#* If you install it into another path, set the environment variable MINGW_PATH to the TDM-MinGW installation directory, e.g. the one containing <tt>README-tdm-gcc.txt</tt> (right click My Computer -> Properties -> Advanced -> Environment Variables).
# Be sure to enable the "GCC -> openmp support" checkbox from the components list

===Create your Launchpad account===
You can skip this step (or do it later) if you just want to download the sources, but not submit your changes.

If you do not have an SSH public/private key pair to identify yourself:
*run the program puttygen.exe to generate an SSH key
*save both its parts.
Log into your Launchpad account, go to your profile page and add the public part of the generated key to the list of SSH keys. Run the program pageant.exe (you can add it to Autorun). A tray icon should appear. Right click it, select "Add Key" and pick the private key file you have just generated from the dialog. Note that you need to repeat this after every login whenever you want to access Launchpad.

Now set up Bazaar. First tell it who you are, then associate with your Launchpad account. You need to use the account name (e.g. johnq), not the display name.(John Q. Public).

C:\> bzr whoami "''Your Name'' <''your_real_email@example.com''>"
C:\> bzr launchpad-login ''your_launchpad_account''

===Install the developer libraries===
Check out Inkscape Devlibs into C:\devlibs. If you check them out elsewhere, set the environment variable DEVLIBS_PATH to the path where they are. Devlibs are a bundle of all the libraries needed to compile Inkscape. If you experience any problems, make sure you have an up to date copy of those libraries and an up to date checkout of Inkscape source. To reduce the size of the download, pass the <tt>--lightweight</tt> parameter.

C:\> bzr checkout --lightweight lp:inkscape-devlibs devlibs

To update devlibs:

C:\devlibs> bzr update

All Inkscape developers can commit to the devlibs trunk. Advanced information about Devlibs, mainy useful when you want to update them to newly released versions of upstream libraries, is available here: [[Inkscape Devlibs]].
You can see some infomation from [https://launchpad.net/inkscape-devlibs launchpad:inkscape-devlibs] and [http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs/trunk/files trunk/files].

== Obtaining Inkscape source code ==

You can obtain released Inkscape source from a tarball. Since version 0.47 they are hosted on [https://launchpad.net/inkscape Inkscape's Launchpad page]. There are ready-made installers provided, so there's usually little reason to compile the stable version yourself.

To obtain cutting edge code, check out Inkscape source from the Bazaar repository. You can also use the TortoiseBZR shell extensions to do this. The recommended way is to first create a shared repository, then check out the Inkscape branch into that shared repository. Using this setup, branching will be a lot faster.

C:\src\inkscape> bzr init-repo --rich-root .
C:\src\inkscape> bzr upgrade
C:\src\inkscape> bzr checkout lp:inkscape trunk

If you don't want to create any branches, you can skip the shared repository step.

C:\src> bzr checkout lp:inkscape

'''IMPORTANT:''' make sure that the path to your Inkscape source checkout does not contain spaces. Unix tools do not like them and you will end up with a lot of error messages about missing files.

== Set Environmental Variables ==

First set up the environmental variables. You need to run mingwenv once per console session like this:
C:\src\inkscape\trunk> mingwenv
Or you can set the paths in the Windows system settings. Go to (Win 7):

Start->Control Panel ->System and Security->System->Advanced system settings->Advanced->Environment variables->System variables->New.
Add these variable names and values: 
DEVLIBS_PATH c:\devlibs 
MINGW_PATH c:\mingw 
MINGW_BIN c:\mingw\bin 
PKG_CONFIG_PATH c:\devlibs \lib\pkgconfig 
CMAKE_PREFIX_PATH c:\devlibs 
GTKMM_BASEPATH c:\devlibs 

Also, edit the PATH variable, and add these if not already present: 
c:\mingw\bin;c:\devlibs\python;c:\devlibs\bin

After the Environment Variables are set in the Windows system settings, a restart is required.

== Compile the Build Tool ==

Now compile the build tool with the following command:

C:\src\inkscape\trunk> g++ buildtool.cpp -o btool -fopenmp

The <code>-fopenmp</code> flag enables [https://gcc.gnu.org/wiki/openmp OpenMP] which allows to use parallel compilation threads when building Inkscape.

== Building Inkscape ==

Finally initiate the compilation. Get a coffee or take your dog out for a walk, because it will take a rather long time. If you have a multicore processor, add "-j 8" to use (for example) 8 parallel compilation threads.

C:\src\inkscape\trunk> btool -j 8

Once everything is done, there should be an <tt>inkscape</tt> directory that contains the Inkscape executable and libraries needed to run it.

== Rebuilding ==

If you have only changed a few files and want to rebuild, delete the <tt>inkscape</tt> directory and run <tt>btool</tt> again.

To rebuild from scratch, execute the following sequence of commands:
C:\src\inkscape\trunk> btool clean
C:\src\inkscape\trunk> btool

== Dealing With Build Errors ==
Feel free to add any questions or answers you have in here;

'''Q''' - My firewall software (Comodo's Defense+ component or similar) stopped the process continuing to the next step in the build, because I wasn't there to permit an action and it timed out. What can I do?

'''A1''' - The best thing is to disable stuff like Defense+ (put it in learning mode works) because it will stop any process that is not approved, and building makes new files which can't be approved before they're built. Disabling Comodo's Defense+ does not disable your firewall, either inbound or outbound, but just the part that scans every application for suspicious operations. Other firewalls etc may vary.

'''A2''' - If that doesn't suit, often you can simply run btool again and wait for Defense+ (or similar) to ask for approval for the process, and it will then continue as normal with the build. But remember that approving all the processes involved in the build process once doesn't mean they will all slip through next time.

'''A3''' - This is the more complex way to continue, but may help if you have problems with A2. If you know the stage the process was meant to be up to (look at the output in the command windows and compare to the stages in the ''build.xml'' file), you can start again from there.

You may see something like this in the command window;
=============================
## Target : link : link objects and library to create executable
---- task : rc
============ cmd ============
windres -o build/inkres.o --include-dir=src src/inkscape.rc
=============================
---- task : link
This will likely be followed by an error message. This means you were at the ''link'' stage

Now simply type;
...>btool ''stage''
Or in this case
...>btool link
And the build will continue from there.

After this, you will probably have to step through the remaining stages manually, one by one. The stages can include (see build.xml, where each stage is labelled 'target name="''target''"') ''init'', ''touchabout'', ''compile'', ''java'', ''lib'', ''i18n'', ''link'', ''linkinkview'', ''dist'', ''dist-all'', ''clean''.

'''Q''' - How do I rebuild just one ''file.o'' file? For instance if one particular file has gone wrong, or I want to try patching just one part of the code.

'''A''' - To find the right command for building any particular file in Inkscape, just look in the compile.lst after you have used btool once. Search for the name of the particular file (eg: print.cpp) and you will find the command used to compile it. You'll need to paste this into a text file, remove any carriage reurns and then paste that onto the command line.

'''Q''' - After I patched a file, I left a backup of the old file in the same directory called Copy of{filename}.cpp. The compiler complains about this file when building and stops.

'''A''' - Do not leave anything with a suffix .cpp in the source directories, apart from the original (or patched) source files. The build tool will try to compile everything ending in .cpp and will complain. If you backup an old file in the same directory before patching, call it {filename}.cpp.old or similar.

'''Q''' - I think I followed the instruction above. What could have caused the compiling error like this for src/extension/internal/pdfinput/pdf-parser.cpp?

src/extension/internal/pdfinput/pdf-parser.cpp:2248: error: no matching function for call to 'GfxFont::getNextChar(char*&, int&, CharCode*, Unicode [8], int, int*, double*, double*, double*, double*)'

Same error for line 2297 as well.

=== For more information ===
There is some old information on building Inkscape with either Mingw on Windows, or a cross-compiler on Linux, at http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html
and old files mey be
http://inkscape.modevia.com/win32libs/
== Creating an installer ==

To create the '''inkscape-$RELEASE-win32.exe''' setup package you need the '''NSIS''' installer on your PC. Get that from http://nsis.sf.net .
You have successfully built Inkscape and everything is in the ...\inkscape\ directory.
Open the ...\packaging\win32\inkscape.nsi using the NSIS program and compile the package. Sooo easy :-)

The new wix installer in the packaging\wix directory creates msi packages. You need the '''windows installer XML''' package; get it from here http://wixtoolset.org/. Follow the instructions in the README file in the packaging\wix directory. The installer scripts parse version information from the inkscape.rc file. The generated packed is named as:

'''inkscape-$RELEASE.msi'''

== Note about Unicode ==

The GTK stack depends on functions only present in NT-based Windows (2000 and later). Therefore, Inkscape code can assume that Unicode functions from the Windows API (like GetCommandLineW) are always present. Note however that you should use the GLib/GTK functions rather the Windows API whenever possible.

=See also=
*[[Compiling Inkscape]]
*[[Using Visual Studio]]

[[Category:Developer Documentation]]

CMake Tasks

2016-04-22T10:52:21Z

Shlomif: Mark "make check" as DONE.

== Priorities for 0.92 ==

* Remove the hardcoded defines in CMakeLists.txt. These are marked out in the "BAD HACKS" section with add_definitions() calls. I suspect many of these are simply unnecessary, like HAVE_CONFIG_H and _FORTIFY_SOURCE. None are documented as to why they were added - perhaps investigate these further, or just test that the build works without them and drop them for now until their need becomes clearer?

* Add locale installation support to the UNIX section in CMakeLists.txt. These are the po files in Inkscape's po/ subdirectory, and at least for me this appears to be working properly. We already have a simple po/CMakeLists.txt that looks like it does the basics already, including a GETTEXT_PROCESS_PO_FILES() call appears to be putting the files in the binary build's share/locale directory, and we're already hooking it in via the add_subdirectory() call in the top level CMakeLists.txt. Probably worth just checking that inkscape with localization turned on is able to find the appropriate po file and provide translated strings in its user interface, and just verify locales are working as expected. (Related: [https://bugs.launchpad.net/inkscape/+bug/1514588 bug #1514588])

* Compare dists created by cmake with dists created by autoconf. Set up parallel build trees for cmake and autoconf, and do a make dist in each. Then unpack the tarballs created by each method, create a sorted recursive file listing for each, and diff them. Filter out the cmake-specific and automake-specific files. Look for files autoconf is including in the dist that cmake isn't, and files that cmake includes that autoconf doesn't. For each file determine if it's needed, and adjust the cmake rules accordingly.

* Review configure.ac and Makefile.ac for other configurable or required features and libraries. For each of these dependencies, verify that cmake is checking for it in the root CMakeLists.txt or one of the included files in CMakeScripts/*.cmake.

* Convert the OS X build system to use cmake ([https://bugs.launchpad.net/inkscape/+bug/1502774 bug #1502774])

* Convert the WIN32 build system to use cmake (specific details needed..._

* '''DONE:''' Drop the checks for getopt.h, since we no longer use that.

* '''DONE:''' Add a test whether '-std=c++11' is required for libsigc++ and/or glibmm/gtkmm ([https://bugs.launchpad.net/inkscape/+bug/1488079 bug #1488079], see comment [https://bugs.launchpad.net/inkscape/+bug/1488079/comments/48 48])

* '''DONE:''' Get 'make check' to work. Presently it generates an error "No test configuration file found!" A lot of the test harness appears to already be set up, so presumably there's just a bit more configuration needed to get it activated. See patch and discussion in [https://bugs.launchpad.net/inkscape/+bug/1554143 bug #1554143].

== Misc. Cleanup and Nice To Haves ==

These tasks are not priorities for 0.92 but don't risk breaking anything beyond cmake so are safe to land any time.

* Avoid clobbering CMAKE_* variables. set(CMAKE_FOO "bar") is wrong, it should be set(CMAKE_FOO "${CMAKE_FOO} bar)

* DefineDependsandFlags.cmake explicitly includes GTK2_* stuff, but would just GTK2_INCLUDE_DIRS and GTK2_LIBRARY_DIRS work?

* Automatically update the author dialog using AUTHORS. Look at how the man pages are updated from AUTHORS in the cmake scripts; the dialog can be updated in a similar manner, just that the names need to be formatted differently for the C++ compilation. TRANSLATORS can be done the same way. Probably COPYING as well.

* Rename FindPANGOMM.cmake to FindPangoMM.cmake, to make file name casing consistent. Perhaps there are other modules that should be renamed for consistency too? Be sure any renames don't break the build when those modules are in use.

* Ensure the man pages rebuild when edited. I don't think I set up the dependency tracking correctly for inkscape.pod.in and the other pod files, because they don't rebuild automatically when modified.

* Improve the pango/cairo configuration logic. DefineDependsandFlags.cmake contains platform checks for which libraries to include specifically, which should be generalized and perhaps moved into FindCairo*.cmake and/or FindPango*.cmake modules. ([https://bugs.launchpad.net/inkscape/+bug/1512379 bug #1512379])

* Restructure the helper cmake scripts. Presently a lot of configuration logic is broken out into CMakeScripts/*.cmake files. Where these contain helper routines or otherwise self-contained chunks of functionality that is reasonably abstracted from Inkscape this is fine, but some of these are really just Inkscape-specific logic that probably would be better to just leave inline in the top CMakeLists.txt file. E.g. DefineDependsandFlags.cmake, ConfigCompileFlags.cmake, and ConfigPaths.cmake should be considered to merge back in. Having them broken out separately just obscures configuration logic, and likely will just make things more inconvenient for developers trying to get a handle on the application's configuration.

* Improve the GTK3 Experimental logic. DefineDependsandFlags.cmake contains a large chunk of code for handling GTK3 libraries. As inkscape itself gets ported to Gtk3, I'm guessing a lot of this build configuration logic will need redone or improved. Probably worthwhile to examine GIMP and other gtk/cmake based projects that may be further along in their Gtk3 conversion.

* ConfigChecks.cmake includes tests for a bunch of basic C functions. Many of these are things I believe we can reasonably assume to be present in modern compilers. It hurts little to retain these if they provide tangible benefits, but they do take up time during configuration, so if they're completely redundant we should just drop them. I think as long as we are requiring minimum versions on particular compilers, or if we're checking for certain C++ standards level compliance of the compilers, we can assume a lot of these functions are already there.

* As a corollary to the previous task, ConfigChecks.cmake should perhaps include checks for header files and function calls that we use, that may not be present in every compiler. C++-11 features, for example, might fit here, or anything that is platform-dependent.

* We include a UsePkgConfig.cmake file, but I wonder if this is actually necessary. Reasonably modern cmake has pkgconfig support built-in, so perhaps with a bit of adjustment we could drop this file? I think we should be able to just do "find_package(PkgConfig REQUIRED)"

* Cleanup rendundant stuff in the root CMakeLists.txt no longer needed in recent versions of cmake. I wonder if some of our cmake_policy() statements are redundant with setting cmake's minimum version to 2.8. Other stuff may simply be restating default values, such as CMAKE_MODULE_PATH.

* Cleanup the version specification and insertion. We set the version in INKSCAPE_VERSION, but cmake allows setting the version via project() now, which might be better. We have some plumbing to communicate the version number into the application's code, namely src/inkscape-version.cpp, which supposedly is generated by inkscape-version.cmake (this should probably be doublechecked, I'm not 100% certain it's actually triggered.) I wonder if much of this is superfluous: cmake is creating config.h from config.h.cmake to supply defines for PACKAGE_VERSION, and we could also add the broken down version bits by using cmake's PROJECT_VERSION_MAJOR, PROJECT_VERSION_MINOR, and PROJECT_VERSION_PATCH if we need that.

* Add [https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html GNUInstallDirs.cmake] and update all installation paths to use the provided variables.

== Post-0.92 ==

The following cmake related projects should be left until after autoconf is dropped, else they'll likely break autoconf or require it to be updated in turn. Easier to wait until after 0.92 when autoconf is scheduled to be dropped.

* Drop the autoconf files: autogen.sh, configure.in, etc. etc.

* Move fix-roff-punct to the packaging/ directory. This is used only by the man page creation routines, and doesn't need to be kept at the top level so long as it can be found by the cmake script that uses it.

* Drop btool-related files. Doublecheck that the win32 and osx packaging tools have switched over to cmake before doing this.

CMake

2016-04-15T16:24:26Z

Shlomif: /* Using CMake to run tests */

'''Work is a on going to get this build system functional!'''

Cmake is a cross-platform build system know to work on all major platforms we support (*nix, Windows, OSX).

CMake is an extensible, open-source system that has many powerful features.
Those features include:

* Supports complex, large build environments. CMake has been proven in several large projects (KDE, ParaView, SecondLife, Scribus)
* Generates native build files (e.g., makefiles on Unix; workspaces/projects on MS Visual C++). Therefore, standard tools can be used on any platform/compiler configuration.
* Powerful system introspection abilities including the ability to find installed include files, libraries and executables. Also the ability to test the compiler for supported features.
* Integrated testing system called CTest.
* Integrated packaging system called CPack.
* Easy integration with CDash and Dart dashboard servers.
* Powerful scripting language with simple syntax.
* Supports in-place and out-of-place builds. Multiple compilation trees are possible from a single source tree.
* Can be easily extended to add new features.
* CMake is open source, under a liberal BSD license.
* CMake operates with a cache designed to be interfaced with a graphical editor. The cache provides optional interaction to conditionally control the build process.
* Ability to create Mac OSX Frameworks and Application Bundles.
* Supports adding complex custom rules to the build.

== How you can help ==

We have completed the building of the CMakeLists.txt for almost everything needed.
We are now working on get the build to compile properly. See below Testing/Using to help.

There is a separate [[CMake Tasks]] page with things that are left to do w.r.t. cmake building of Inkscape.

== SIMPLE CmakeLists.txt ==
SET(libavoid_SRC
connector.cpp
geometry.cpp
graph.cpp
makepath.cpp
polyutil.cpp
region.cpp
router.cpp
shape.cpp
static.cpp
timer.cpp
vertices.cpp
visibility.cpp
)

== SIMPLE with single sub-directory Cmakelists.txt ==

SET(libavoid_SRC
connector.cpp
geometry.cpp
graph.cpp
makepath.cpp
polyutil.cpp
region.cpp
router.cpp
shape.cpp
static.cpp
timer.cpp
vertices.cpp
visibility.cpp
#Add our subdirectory sourcelist Var
${libavoid_parameter_SRC}
)
# this adds a single sub-directory
ADD_SUBDIRECTORY(parameter)

== Using CMake to build Inkscape ==

Experience with Scribus '''strongly''' suggests using an "out of source"build arrangement. E.g.

<pre>
mkdir buildinkscape
cd buildinkscape
cmake ./path/to/inkscape/sources
make
</pre>

References:
[http://docs.scribus.net/index.php?lang=en&page=install4 Installing Scribus with Cmake] 
[http://docs.scribus.net/index.php?lang=en&page=install5 Installing with CMake on OSX]

== Using CMake to run tests ==

First, install Google Test framework by running download-gtest.sh in the main directory of inkscape source:

<pre>
cd /path/to/inkscape
bash download-gtest.sh
</pre>

Then, toggle the CMake config var "WITH_GTEST" to ON, e.g. by editing CMakeCache.txt or by using ccmake or by passing "-DWITH_GTEST=ON" to cmake. Don't forget to re-run cmake after the configuration change:

<pre>
cd /path/to/buildinkscape
# modify CMakeCache.txt
cmake ../inkscape
</pre>

Finally, run "make check" from same directory to run the tests:

<pre>
make check
</pre>

CMake Tasks

2016-04-07T09:01:07Z

Shlomif: Add the link to the bug with the patch.

== Priorities for 0.92 ==

* Remove the hardcoded defines in CMakeLists.txt. These are marked out in the "BAD HACKS" section with add_definitions() calls. I suspect many of these are simply unnecessary, like HAVE_CONFIG_H and _FORTIFY_SOURCE. None are documented as to why they were added - perhaps investigate these further, or just test that the build works without them and drop them for now until their need becomes clearer?

* Add locale installation support to the UNIX section in CMakeLists.txt. These are the po files in Inkscape's po/ subdirectory, and at least for me this appears to be working properly. We already have a simple po/CMakeLists.txt that looks like it does the basics already, including a GETTEXT_PROCESS_PO_FILES() call appears to be putting the files in the binary build's share/locale directory, and we're already hooking it in via the add_subdirectory() call in the top level CMakeLists.txt. Probably worth just checking that inkscape with localization turned on is able to find the appropriate po file and provide translated strings in its user interface, and just verify locales are working as expected. (Related: [https://bugs.launchpad.net/inkscape/+bug/1514588 bug #1514588])

* Compare dists created by cmake with dists created by autoconf. Set up parallel build trees for cmake and autoconf, and do a make dist in each. Then unpack the tarballs created by each method, create a sorted recursive file listing for each, and diff them. Filter out the cmake-specific and automake-specific files. Look for files autoconf is including in the dist that cmake isn't, and files that cmake includes that autoconf doesn't. For each file determine if it's needed, and adjust the cmake rules accordingly.

* Review configure.ac and Makefile.ac for other configurable or required features and libraries. For each of these dependencies, verify that cmake is checking for it in the root CMakeLists.txt or one of the included files in CMakeScripts/*.cmake.

* Get 'make check' to work. Presently it generates an error "No test configuration file found!" A lot of the test harness appears to already be set up, so presumably there's just a bit more configuration needed to get it activated. See patch and discussion in [https://bugs.launchpad.net/inkscape/+bug/1554143 bug #1554143].

* Convert the OS X build system to use cmake ([https://bugs.launchpad.net/inkscape/+bug/1502774 bug #1502774])

* Convert the WIN32 build system to use cmake (specific details needed..._

* '''DONE:''' Drop the checks for getopt.h, since we no longer use that.

* '''DONE:''' Add a test whether '-std=c++11' is required for libsigc++ and/or glibmm/gtkmm ([https://bugs.launchpad.net/inkscape/+bug/1488079 bug #1488079], see comment [https://bugs.launchpad.net/inkscape/+bug/1488079/comments/48 48])

== Misc. Cleanup and Nice To Haves ==

These tasks are not priorities for 0.92 but don't risk breaking anything beyond cmake so are safe to land any time.

* Avoid clobbering CMAKE_* variables. set(CMAKE_FOO "bar") is wrong, it should be set(CMAKE_FOO "${CMAKE_FOO} bar)

* DefineDependsandFlags.cmake explicitly includes GTK2_* stuff, but would just GTK2_INCLUDE_DIRS and GTK2_LIBRARY_DIRS work?

* Automatically update the author dialog using AUTHORS. Look at how the man pages are updated from AUTHORS in the cmake scripts; the dialog can be updated in a similar manner, just that the names need to be formatted differently for the C++ compilation. TRANSLATORS can be done the same way. Probably COPYING as well.

* Rename FindPANGOMM.cmake to FindPangoMM.cmake, to make file name casing consistent. Perhaps there are other modules that should be renamed for consistency too? Be sure any renames don't break the build when those modules are in use.

* Ensure the man pages rebuild when edited. I don't think I set up the dependency tracking correctly for inkscape.pod.in and the other pod files, because they don't rebuild automatically when modified.

* Improve the pango/cairo configuration logic. DefineDependsandFlags.cmake contains platform checks for which libraries to include specifically, which should be generalized and perhaps moved into FindCairo*.cmake and/or FindPango*.cmake modules. ([https://bugs.launchpad.net/inkscape/+bug/1512379 bug #1512379])

* Restructure the helper cmake scripts. Presently a lot of configuration logic is broken out into CMakeScripts/*.cmake files. Where these contain helper routines or otherwise self-contained chunks of functionality that is reasonably abstracted from Inkscape this is fine, but some of these are really just Inkscape-specific logic that probably would be better to just leave inline in the top CMakeLists.txt file. E.g. DefineDependsandFlags.cmake, ConfigCompileFlags.cmake, and ConfigPaths.cmake should be considered to merge back in. Having them broken out separately just obscures configuration logic, and likely will just make things more inconvenient for developers trying to get a handle on the application's configuration.

* Improve the GTK3 Experimental logic. DefineDependsandFlags.cmake contains a large chunk of code for handling GTK3 libraries. As inkscape itself gets ported to Gtk3, I'm guessing a lot of this build configuration logic will need redone or improved. Probably worthwhile to examine GIMP and other gtk/cmake based projects that may be further along in their Gtk3 conversion.

* ConfigChecks.cmake includes tests for a bunch of basic C functions. Many of these are things I believe we can reasonably assume to be present in modern compilers. It hurts little to retain these if they provide tangible benefits, but they do take up time during configuration, so if they're completely redundant we should just drop them. I think as long as we are requiring minimum versions on particular compilers, or if we're checking for certain C++ standards level compliance of the compilers, we can assume a lot of these functions are already there.

* As a corollary to the previous task, ConfigChecks.cmake should perhaps include checks for header files and function calls that we use, that may not be present in every compiler. C++-11 features, for example, might fit here, or anything that is platform-dependent.

* We include a UsePkgConfig.cmake file, but I wonder if this is actually necessary. Reasonably modern cmake has pkgconfig support built-in, so perhaps with a bit of adjustment we could drop this file? I think we should be able to just do "find_package(PkgConfig REQUIRED)"

* Cleanup rendundant stuff in the root CMakeLists.txt no longer needed in recent versions of cmake. I wonder if some of our cmake_policy() statements are redundant with setting cmake's minimum version to 2.8. Other stuff may simply be restating default values, such as CMAKE_MODULE_PATH.

* Cleanup the version specification and insertion. We set the version in INKSCAPE_VERSION, but cmake allows setting the version via project() now, which might be better. We have some plumbing to communicate the version number into the application's code, namely src/inkscape-version.cpp, which supposedly is generated by inkscape-version.cmake (this should probably be doublechecked, I'm not 100% certain it's actually triggered.) I wonder if much of this is superfluous: cmake is creating config.h from config.h.cmake to supply defines for PACKAGE_VERSION, and we could also add the broken down version bits by using cmake's PROJECT_VERSION_MAJOR, PROJECT_VERSION_MINOR, and PROJECT_VERSION_PATCH if we need that.

* Add [https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html GNUInstallDirs.cmake] and update all installation paths to use the provided variables.

== Post-0.92 ==

The following cmake related projects should be left until after autoconf is dropped, else they'll likely break autoconf or require it to be updated in turn. Easier to wait until after 0.92 when autoconf is scheduled to be dropped.

* Drop the autoconf files: autogen.sh, configure.in, etc. etc.

* Move fix-roff-punct to the packaging/ directory. This is used only by the man page creation routines, and doesn't need to be kept at the top level so long as it can be found by the cmake script that uses it.

* Drop btool-related files. Doublecheck that the win32 and osx packaging tools have switched over to cmake before doing this.

CMake Tasks

2016-02-27T17:21:37Z

Shlomif: Mark an item as done.

== Priorities for 0.92 ==

* Remove the hardcoded defines in CMakeLists.txt. These are marked out in the "BAD HACKS" section with add_definitions() calls. I suspect many of these are simply unnecessary, like HAVE_CONFIG_H and _FORTIFY_SOURCE. None are documented as to why they were added - perhaps investigate these further, or just test that the build works without them and drop them for now until their need becomes clearer?

* Add locale installation support to the UNIX section in CMakeLists.txt. These are the po files in Inkscape's po/ subdirectory, and at least for me this appears to be working properly. We already have a simple po/CMakeLists.txt that looks like it does the basics already, including a GETTEXT_PROCESS_PO_FILES() call appears to be putting the files in the binary build's share/locale directory, and we're already hooking it in via the add_subdirectory() call in the top level CMakeLists.txt. Probably worth just checking that inkscape with localization turned on is able to find the appropriate po file and provide translated strings in its user interface, and just verify locales are working as expected. (Related: [https://bugs.launchpad.net/inkscape/+bug/1514588 bug #1514588])

* Compare dists created by cmake with dists created by autoconf. Set up parallel build trees for cmake and autoconf, and do a make dist in each. Then unpack the tarballs created by each method, create a sorted recursive file listing for each, and diff them. Filter out the cmake-specific and automake-specific files. Look for files autoconf is including in the dist that cmake isn't, and files that cmake includes that autoconf doesn't. For each file determine if it's needed, and adjust the cmake rules accordingly.

* Review configure.ac and Makefile.ac for other configurable or required features and libraries. For each of these dependencies, verify that cmake is checking for it in the root CMakeLists.txt or one of the included files in CMakeScripts/*.cmake.

* Get 'make check' to work. Presently it generates an error "No test configuration file found!" A lot of the test harness appears to already be set up, so presumably there's just a bit more configuration needed to get it activated.

* Convert the OS X build system to use cmake ([https://bugs.launchpad.net/inkscape/+bug/1502774 bug #1502774])

* Convert the WIN32 build system to use cmake

* '''DONE:''' Drop the checks for getopt.h, since we no longer use that.

* '''DONE:''' Add a test whether '-std=c++11' is required for libsigc++ and/or glibmm/gtkmm ([https://bugs.launchpad.net/inkscape/+bug/1488079 bug #1488079], see comment [https://bugs.launchpad.net/inkscape/+bug/1488079/comments/48 48])

== Misc. Cleanup and Nice To Haves ==

These tasks are not priorities for 0.92 but don't risk breaking anything beyond cmake so are safe to land any time.

* Avoid clobbering CMAKE_* variables. set(CMAKE_FOO "bar") is wrong, it should be set(CMAKE_FOO "${CMAKE_FOO} bar)

* DefineDependsandFlags.cmake explicitly includes GTK2_* stuff, but would just GTK2_INCLUDE_DIRS and GTK2_LIBRARY_DIRS work?

* Automatically update the author dialog using AUTHORS. Look at how the man pages are updated from AUTHORS in the cmake scripts; the dialog can be updated in a similar manner, just that the names need to be formatted differently for the C++ compilation. TRANSLATORS can be done the same way. Probably COPYING as well.

* Rename FindPANGOMM.cmake to FindPangoMM.cmake, to make file name casing consistent. Perhaps there are other modules that should be renamed for consistency too? Be sure any renames don't break the build when those modules are in use.

* Ensure the man pages rebuild when edited. I don't think I set up the dependency tracking correctly for inkscape.pod.in and the other pod files, because they don't rebuild automatically when modified.

* Improve the pango/cairo configuration logic. DefineDependsandFlags.cmake contains platform checks for which libraries to include specifically, which should be generalized and perhaps moved into FindCairo*.cmake and/or FindPango*.cmake modules. ([https://bugs.launchpad.net/inkscape/+bug/1512379 bug #1512379])

* Restructure the helper cmake scripts. Presently a lot of configuration logic is broken out into CMakeScripts/*.cmake files. Where these contain helper routines or otherwise self-contained chunks of functionality that is reasonably abstracted from Inkscape this is fine, but some of these are really just Inkscape-specific logic that probably would be better to just leave inline in the top CMakeLists.txt file. E.g. DefineDependsandFlags.cmake, ConfigCompileFlags.cmake, and ConfigPaths.cmake should be considered to merge back in. Having them broken out separately just obscures configuration logic, and likely will just make things more inconvenient for developers trying to get a handle on the application's configuration.

* Improve the GTK3 Experimental logic. DefineDependsandFlags.cmake contains a large chunk of code for handling GTK3 libraries. As inkscape itself gets ported to Gtk3, I'm guessing a lot of this build configuration logic will need redone or improved. Probably worthwhile to examine GIMP and other gtk/cmake based projects that may be further along in their Gtk3 conversion.

* ConfigChecks.cmake includes tests for a bunch of basic C functions. Many of these are things I believe we can reasonably assume to be present in modern compilers. It hurts little to retain these if they provide tangible benefits, but they do take up time during configuration, so if they're completely redundant we should just drop them. I think as long as we are requiring minimum versions on particular compilers, or if we're checking for certain C++ standards level compliance of the compilers, we can assume a lot of these functions are already there.

* As a corollary to the previous task, ConfigChecks.cmake should perhaps include checks for header files and function calls that we use, that may not be present in every compiler. C++-11 features, for example, might fit here, or anything that is platform-dependent.

* We include a UsePkgConfig.cmake file, but I wonder if this is actually necessary. Reasonably modern cmake has pkgconfig support built-in, so perhaps with a bit of adjustment we could drop this file? I think we should be able to just do "find_package(PkgConfig REQUIRED)"

* Cleanup rendundant stuff in the root CMakeLists.txt no longer needed in recent versions of cmake. I wonder if some of our cmake_policy() statements are redundant with setting cmake's minimum version to 2.8. Other stuff may simply be restating default values, such as CMAKE_MODULE_PATH.

* Cleanup the version specification and insertion. We set the version in INKSCAPE_VERSION, but cmake allows setting the version via project() now, which might be better. We have some plumbing to communicate the version number into the application's code, namely src/inkscape-version.cpp, which supposedly is generated by inkscape-version.cmake (this should probably be doublechecked, I'm not 100% certain it's actually triggered.) I wonder if much of this is superfluous: cmake is creating config.h from config.h.cmake to supply defines for PACKAGE_VERSION, and we could also add the broken down version bits by using cmake's PROJECT_VERSION_MAJOR, PROJECT_VERSION_MINOR, and PROJECT_VERSION_PATCH if we need that.

* Add [https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html GNUInstallDirs.cmake] and update all installation paths to use the provided variables.

== Post-0.92 ==

The following cmake related projects should be left until after autoconf is dropped, else they'll likely break autoconf or require it to be updated in turn. Easier to wait until after 0.92 when autoconf is scheduled to be dropped.

* Drop the autoconf files: autogen.sh, configure.in, etc. etc.

* Move fix-roff-punct to the packaging/ directory. This is used only by the man page creation routines, and doesn't need to be kept at the top level so long as it can be found by the cmake script that uses it.

* Drop btool-related files. Doublecheck that the win32 and osx packaging tools have switched over to cmake before doing this.

CMake Tasks

2016-02-26T16:08:16Z

Shlomif: Update a completed task and fix misspelling.

== Priorities for 0.92 ==

* Remove the hardcoded defines in CMakeLists.txt. These are marked out in the "BAD HACKS" section with add_definitions() calls. I suspect many of these are simply unnecessary, like HAVE_CONFIG_H and _FORTIFY_SOURCE. None are documented as to why they were added - perhaps investigate these further, or just test that the build works without them and drop them for now until their need becomes clearer?

* Add locale installation support to the UNIX section in CMakeLists.txt. These are the po files in Inkscape's po/ subdirectory, and at least for me this appears to be working properly. We already have a simple po/CMakeLists.txt that looks like it does the basics already, including a GETTEXT_PROCESS_PO_FILES() call appears to be putting the files in the binary build's share/locale directory, and we're already hooking it in via the add_subdirectory() call in the top level CMakeLists.txt. Probably worth just checking that inkscape with localization turned on is able to find the appropriate po file and provide translated strings in its user interface, and just verify locales are working as expected. (Related: [https://bugs.launchpad.net/inkscape/+bug/1514588 bug #1514588])

* Compare dists created by cmake with dists created by autoconf. Set up parallel build trees for cmake and autoconf, and do a make dist in each. Then unpack the tarballs created by each method, create a sorted recursive file listing for each, and diff them. Filter out the cmake-specific and automake-specific files. Look for files autoconf is including in the dist that cmake isn't, and files that cmake includes that autoconf doesn't. For each file determine if it's needed, and adjust the cmake rules accordingly.

* Review configure.ac and Makefile.ac for other configurable or required features and libraries. For each of these dependencies, verify that cmake is checking for it in the root CMakeLists.txt or one of the included files in CMakeScripts/*.cmake.

* Add a test whether '-std=c++11' is required for libsigc++ and/or glibmm/gtkmm ([https://bugs.launchpad.net/inkscape/+bug/1488079 bug #1488079], see comment [https://bugs.launchpad.net/inkscape/+bug/1488079/comments/48 48])

* Get 'make check' to work. Presently it generates an error "No test configuration file found!" A lot of the test harness appears to already be set up, so presumably there's just a bit more configuration needed to get it activated.

* Convert the OS X build system to use cmake ([https://bugs.launchpad.net/inkscape/+bug/1502774 bug #1502774])

* Convert the WIN32 build system to use cmake

* '''DONE:''' Drop the checks for getopt.h, since we no longer use that.

== Misc. Cleanup and Nice To Haves ==

These tasks are not priorities for 0.92 but don't risk breaking anything beyond cmake so are safe to land any time.

* Avoid clobbering CMAKE_* variables. set(CMAKE_FOO "bar") is wrong, it should be set(CMAKE_FOO "${CMAKE_FOO} bar)

* DefineDependsandFlags.cmake explicitly includes GTK2_* stuff, but would just GTK2_INCLUDE_DIRS and GTK2_LIBRARY_DIRS work?

* Automatically update the author dialog using AUTHORS. Look at how the man pages are updated from AUTHORS in the cmake scripts; the dialog can be updated in a similar manner, just that the names need to be formatted differently for the C++ compilation. TRANSLATORS can be done the same way. Probably COPYING as well.

* Rename FindPANGOMM.cmake to FindPangoMM.cmake, to make file name casing consistent. Perhaps there are other modules that should be renamed for consistency too? Be sure any renames don't break the build when those modules are in use.

* Ensure the man pages rebuild when edited. I don't think I set up the dependency tracking correctly for inkscape.pod.in and the other pod files, because they don't rebuild automatically when modified.

* Improve the pango/cairo configuration logic. DefineDependsandFlags.cmake contains platform checks for which libraries to include specifically, which should be generalized and perhaps moved into FindCairo*.cmake and/or FindPango*.cmake modules. ([https://bugs.launchpad.net/inkscape/+bug/1512379 bug #1512379])

* Restructure the helper cmake scripts. Presently a lot of configuration logic is broken out into CMakeScripts/*.cmake files. Where these contain helper routines or otherwise self-contained chunks of functionality that is reasonably abstracted from Inkscape this is fine, but some of these are really just Inkscape-specific logic that probably would be better to just leave inline in the top CMakeLists.txt file. E.g. DefineDependsandFlags.cmake, ConfigCompileFlags.cmake, and ConfigPaths.cmake should be considered to merge back in. Having them broken out separately just obscures configuration logic, and likely will just make things more inconvenient for developers trying to get a handle on the application's configuration.

* Improve the GTK3 Experimental logic. DefineDependsandFlags.cmake contains a large chunk of code for handling GTK3 libraries. As inkscape itself gets ported to Gtk3, I'm guessing a lot of this build configuration logic will need redone or improved. Probably worthwhile to examine GIMP and other gtk/cmake based projects that may be further along in their Gtk3 conversion.

* ConfigChecks.cmake includes tests for a bunch of basic C functions. Many of these are things I believe we can reasonably assume to be present in modern compilers. It hurts little to retain these if they provide tangible benefits, but they do take up time during configuration, so if they're completely redundant we should just drop them. I think as long as we are requiring minimum versions on particular compilers, or if we're checking for certain C++ standards level compliance of the compilers, we can assume a lot of these functions are already there.

* As a corollary to the previous task, ConfigChecks.cmake should perhaps include checks for header files and function calls that we use, that may not be present in every compiler. C++-11 features, for example, might fit here, or anything that is platform-dependent.

* We include a UsePkgConfig.cmake file, but I wonder if this is actually necessary. Reasonably modern cmake has pkgconfig support built-in, so perhaps with a bit of adjustment we could drop this file? I think we should be able to just do "find_package(PkgConfig REQUIRED)"

* Cleanup rendundant stuff in the root CMakeLists.txt no longer needed in recent versions of cmake. I wonder if some of our cmake_policy() statements are redundant with setting cmake's minimum version to 2.8. Other stuff may simply be restating default values, such as CMAKE_MODULE_PATH.

* Cleanup the version specification and insertion. We set the version in INKSCAPE_VERSION, but cmake allows setting the version via project() now, which might be better. We have some plumbing to communicate the version number into the application's code, namely src/inkscape-version.cpp, which supposedly is generated by inkscape-version.cmake (this should probably be doublechecked, I'm not 100% certain it's actually triggered.) I wonder if much of this is superfluous: cmake is creating config.h from config.h.cmake to supply defines for PACKAGE_VERSION, and we could also add the broken down version bits by using cmake's PROJECT_VERSION_MAJOR, PROJECT_VERSION_MINOR, and PROJECT_VERSION_PATCH if we need that.

* Add [https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html GNUInstallDirs.cmake] and update all installation paths to use the provided variables.

== Post-0.92 ==

The following cmake related projects should be left until after autoconf is dropped, else they'll likely break autoconf or require it to be updated in turn. Easier to wait until after 0.92 when autoconf is scheduled to be dropped.

* Drop the autoconf files: autogen.sh, configure.in, etc. etc.

* Move fix-roff-punct to the packaging/ directory. This is used only by the man page creation routines, and doesn't need to be kept at the top level so long as it can be found by the cmake script that uses it.

* Drop btool-related files. Doublecheck that the win32 and osx packaging tools have switched over to cmake before doing this.

Working with Bazaar

2015-10-26T08:05:25Z

Shlomif: Correct a typo.

This page contains an introduction to the Bazaar distributed version control system. It focuses on the use of Bazaar to develop Inkscape, but should be useful to all would-be users of Bazaar.

You can choose either to use the command line or to use ''Bazaar Explorer'' (get the package ''bzr-explorer'' and follow the [http://doc.bazaar.canonical.com/explorer/en/tutorials/foss-contribute.html Bazaar Explorer Tutorial].

==Why version control is useful==

NOTE: skip this section if you have experience with any version control system.

If you ever worked on some large document in a group without any dedicated software, you have probably encountered the problem of simultaneous modification. When two people add something to the document at the same time, then send their version to each other, no one has the correct version. One of them has to redo their work in the other's version to merge the changes. This process is tedious and time-consuming, and the time spent on merging grows significantly when more people are added to the project.

Fortunately, for text files, this task is simple enough that it can be done automatically by a special program. When merging is done by software, people have more time to focus on productive work.

Version control systems (VCS) are programs designed to eliminate the overhead of merging. They manage a set of text files and allow many people to simultaneously work on them, then periodically submit their changes to a shared location. When two people change the same file, the changes are automatically merged together. Version control systems also store the complete history of changes. When someone makes a mistake and only spots it much later, it can be easily corrected, without affecting later work by other people.

==Version control basics==

Most version control systems use some shared location to publish the most up-to-date version of the project. (We will from now on assume that the project contains the source code for a program.) We will call this place the '''trunk'''. The first thing to do when starting work on a project is to download its source code, which is called creating a '''checkout'''. The files in your checkout are called the '''working copy'''. A checkout contains copies of files belonging to the project, where you can make changes. When you are ready to send your changes to others, you '''commit''' them, and they are stored in the shared location for others to see. The state of the project after someone's changes is called a '''revision''', and each revision in Bazaar is assigned a sequential number, called the '''revision number'''. Revision 0 is the empty project and revision 1 is the initial commit of the project's files. To receive the latest changes introduced by others, you '''update''' your checkout. The update command does not remove any of your uncommitted changes - they are automatically merged.

Bazaar uses the following commands for the above functionality.
$ bzr checkout ''project_trunk_url''
This checks out the source code of a project stored at the specified URL.
$ bzr commit
This sends your changes to the shared location, so others can see them. It will display an editor window, where you should enter the summary of your changes. This description will be visible when using the <tt>bzr log</tt> command.
$ bzr update
This updates your working copy to the latest public revision. Your uncommitted changes are left in place and automatically merged with others' changes.

===Useful basic commands===
$ bzr revert ''file''
This undoes all of your changes to the specified file and restores it to the state it was in after the last update.
$ bzr add ''file''
When you create a new file it is initially '''unversioned''', which means the version control system doesn't track changes to it. You need to tell the VCS that you want to include it in the project, or make it '''versioned'''. The <tt>add</tt> command is used to do this. The next <tt>commit</tt> command will then add this file to the shared location.
$ bzr rm ''file''
This removes a file and its contents from version control and deletes it from disk. The next <tt>commit</tt> command will remove it from the shared location. Use the <tt>--keep</tt> option if you want to remove the shared location but keep it as an unversioned file in your working copy.

===Inspecting project history===

Display last 20 sets of changes (revisions):
$ bzr log -l20

Display all changes to some file since the beginning of project history:
$ bzr log ''file''

===Inspecting changes===

Display all uncommitted changes:
$ bzr diff

Display all changes, both committed and uncommitted, from revision 340:
$ bzr diff -r340

Display changes introduced by revision 436:
$ bzr diff -c436

Display changes between revisions 252 and 260:
$ bzr diff -r252..260

===Undoing mistakes===

To remove all your uncommitted changes:
$ bzr revert

To revert a specific file to the state from revision 230:
$ bzr revert -r230 ''file''

Let's say you committed some change, but then after some time realized it was very wrong. To back it out without affecting any later changes, you need to find the revision number of the change using the <tt>bzr log</tt> command. Let's say want to undo changes from revision 340. To do this, write:
$ bzr merge -r340..339

In the same way, you can undo any set of contiguous revisions, e.g.
$ bzr merge -r340..320

To undo sets of non-contiguous revisions, you have to use one command per set. All commands after the first need to use the --force option (by default Bazaar will refuse to do a merge if there are uncommitted changes).
$ bzr merge -r340..339
$ bzr merge -r327..326 --force
$ bzr merge -r289..286 --force

To actually make the above changes in the shared location, you need to follow them with <tt>bzr commit</tt>. The exception is <tt>bzr revert</tt>, which restores the state to the last committed revision, so there is nothing to commit after it.

===Conflict resolution===

Sometimes two people change the same file in a way that cannot be automatically merged, for example, they change the same line to something different. When this happens, you need to merge the problematic bits manually. You might encounter output like this:

$ bzr update
M src/painting-algorithm.cpp
M src/ui/widget/spinner.h
M src/ui/widget/spinner.cpp
M src/ui/widget/awesome-widget.cpp
Text conflict in src/ui/widget/spinner.cpp
1 conflict encountered.
Updated to revision 1337 of branch [some URL]

After that, the directory <tt>src/ui/widget</tt> will contain four related files.
* <tt>spinner.cpp</tt>: this will contain an unified view of the conflicts in the file. Conflicts will be marked with lines with multiple consecutive angle brackets.
* <tt>spinner.cpp.BASE</tt>: latest common ancestor version of the file. In other words, both you and other people started from this version before conflicting changes were made.
* <tt>spinner.cpp.THIS</tt>: the file with your changes, with conflicting changes by others removed.
* <tt>spinner.cpp.OTHER</tt>: the file with other people's changes, with your conflicting changes removed.

To display the list of conflicts again, use the command:
$ bzr conflicts

To resolve the conflict, you need to modify the contents of the <tt>spinner.cpp</tt>. You can do this either by manually editing the file, by overwriting it with <tt>spinner.cpp.BASE</tt>, <tt>spinner.cpp.THIS</tt> or <tt>spinner.cpp.OTHER</tt>, or by using special options to the resolve command. Once you are done, you need to tell Bazaar about it:
$ bzr resolve src/ui/widget/spinner.cpp

You can tell Bazaar to use your version or others' version, respectively, with the following commands:
$ bzr resolve --take-this ''file''
$ bzr resolve --take-other ''file''

The above command will delete the files <tt>spinner.cpp.BASE</tt>, <tt>spinner.cpp.THIS</tt> and <tt>spinner.cpp.OTHER</tt>. Manually deleting those files has the same effect as executing <tt>bzr resolve</tt>. If you resolve all the conflicts at once, you can tell Bazaar to clean up everything:
$ bzr resolve --all

More information is available here: [http://doc.bazaar.canonical.com/latest/en/user-guide/resolving_conflicts.html Bazaar manual - Conflict handling].

===Determining who made a change===

Sometimes it is useful to see who last changed some lines in a file.
$ bzr annotate ''file''
This will display the entire ''file''. Each line will be prefixed with the revision when the line was last changed and the person which committed that revision. Another name for this command, which might be easier to remember, is <tt>bzr blame</tt>.

==Distributed VCS concepts in Bazaar==

This section assumes that you are familiar with the basic concepts of version control, like working copy, committing, updating, conflicts.

; '''Branch'''
: is a working copy of the project's code. Typically you use one branch per set of related changes, for example a new output extension. Once your work is finished, you ''merge'' your branch into a larger project. Initially, there is only one branch, the trunk; all other branches are its (probably indirect) descendants. To create a new branch, you have to copy an existing one. When branches A and B have a common ancestor branch but each contain changes not present in the other, they have '''diverged'''. For example, when you work on an improved rectangle tool in your own branch and at the same time somebody else applies a PDF export bugfix to the trunk, your rectangle tool branch becomes diverged from the trunk.
; '''Checkout'''
: is a copy of code contained in a branch that is not stored on your computer (a remote branch). Committing to a checkout will immediately apply the changes to the remote branch. Commits will not succeed if somebody else modified the branch while you were working - you need to have an up-to-date working copy - or when you're offline.
; '''Trunk'''
: is the main branch, which represents cutting-edge working code. You should start from it when doing any new development.
; '''Merge'''
: is the process of reconciling changes made between two branches since they diverged. This operation is asymmetric. When you merge A into B, all changes made to A since it was branched from B are applied to B. A is not changed. When you work on some feature, you typically work in a branch, periodically merging the trunk into your branch (to sync up with the latest changes), then you merge your work into the trunk. Merging is similar to applying a patch - it only changes your working copy. To apply a merge, you need to commit the changes it introduced. Merging un-diverges branches.
; '''Repository'''
: is a place where branches of a project are stored. Having a shared repository reduces the storage requirements of multiple branches of one project. Instead of O(number of branches) space, the Bazaar data takes up O(total size of changes in all branches) space.
; '''Bind'''
: is the process of converting a non-diverged local branch into a checkout of the remote branch.
; '''Push'''
: is the process of publishing an exact copy (a mirror) of your branch in some other location. The difference between pushing and checkouts is that a checked out remote branch is updated every time you commit, while a pushed remote branch is updated only when you push to it - you can commit any amount of changes between pushes. You can only push to a branch if the mirror has not diverged from your local copy. This can happen if more than 1 person can push to the same location.
; '''Pull'''
: is the process of creating a local exact copy (mirror) of a branch, in principle a reverse of pushing.

==First steps==

First you need to tell Bazaar your name. This will appear on all your commits. You should use your real e-mail, but you can obfuscate it if you are afraid of spam.

Obfuscated e-mail examples:
$ bzr whoami "John Q. Public <john dot q dot public at-sign bigmail dot com>"
$ bzr whoami "John Q. Public <removethis.john.q.public@bigmail.com>"
Unobfuscated e-mail example:
$ bzr whoami "John Q. Public <john.q.public@bigmail.com>"

If you have an account on Launchpad and want to commit changes there, you need to specify your Launchpad login. You can skip this if you do not intend to commit.
$ bzr launchpad-login johnq

Then fetch Inkscape's trunk
$ bzr checkout lp:inkscape

To carry out a later update of Inkscape's trunk
$ bzr update lp:inkscape

==Using a centralized (SVN-like) workflow==

In this case, every commit that you make is immediately sent to the central repository. There are two ways of achieving this:

===SVN-style checkout===

Get the latest Inkscape code as a checkout, as described above.
$ bzr checkout lp:inkscape

Now work as in SVN:
<do work>
$ bzr commit
<error, someone else has changed things>
$ bzr update
<check all is okay>
$ bzr commit

If you add new files, add them to version control with <tt>bzr add ''file''</tt>. You can recursively add all new files by writing simply <tt>bzr add</tt> in the top level directory.

===Binding a Bazaar branch===

Branch Inkscape's code:
$ bzr branch lp:inkscape

Then transform your branch into a checkout:
$ cd inkscape
$ bzr bind lp:inkscape

Now work as in SVN:
<do work>
$ bzr commit
<error, someone else has changed things>
$ bzr update
<check all is okay>
$ bzr commit

===Differences from SVN===

* Commits will fail if your checkout is not up to date, even if there would be no conflicts.
* The revision number is an attribute of the working tree, not of individual files. It is not possible to have different portions of the working tree at different revisions.
* <tt>bzr commit ''file''</tt> works like <tt> svn commit ''file'' && svn update ''project-root''</tt>. After a successful partial commit, the entire tree's revision is increased by 1.
* No special server is needed to publish a branch. You can push branches to anywhere, including simple FTP shares. In our scenario, Launchpad works like a central repository, but it's not required to publish everything there.
* You create branches locally. To simulate creating a SVN-style branch on Launchpad, you need to create a local branch, push it, then bind it to the pushed location. At the end of these commands you end up with a checkout of <tt>lp:~inkscape.dev/inkscape/killer-feature</tt>:
$ bzr branch trunk killer-feature
$ cd killer-feature
<do work>
$ bzr push lp:~inkscape.dev/inkscape/killer-feature
$ bzr bind :push

===Append-only branches===

In the centralized workflow, you often want to ensure that revision numbering is immutable. In Bazaar, the revision log and numbering can differ depending on which way you merge (e.g. feature into trunk vs trunk into feature). To enforce immutable, monotonically increasing revision numbers on a branch, you can create it as append-only:
$ bzr init --append-revisions-only
To set the append-only flag on an already existing branch, use the following command:
$ bzr config -d ''url://of/branch'' append_revisions_only=True
You can learn the URL of a remote branch by using the command <tt>bzr info</tt>. Launchpad branches have URLs such as <tt>bzr+ssh://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/</tt>

==Using a decentralized workflow==

In this case you will be working locally until you are ready to publish your changes. The basic idea is to perform the work in a ''branch'' of the Inkscape codebase, since committing to a branch stores the changes locally in the branch itself. Then, to share the work with the rest of the Inkscape community, the changes in the branch are merged across to a ''checkout'' of the Inkscape repository. As the previous centralized workflow section describes, committing to a checkout sends the changes directly to the remote repository, making them part of the official Inkscape codebase.

'''NOTE:''' this workflow has been updated to avoid the "other people's commits become subrevisions of your commit" problem.

This will assume this directory layout:
inkscape
+-trunk
| +-doc
| +-share
| +-src
| +-po
| +-...
+-myproject
+-some-other-branch

In this layout, "trunk" is the checkout used for uploading changes to the central Inkscape repository, while "myproject" and "some-other-branch" are local branches used for working on specific features.

===Repository setup===

To speed things up, it's good to create a local shared repository. This way revision histories will only be stored in one place, instead of in every branch, so local branching will be faster and the branches will take up less space.

Create a shared repository and enter it:
$ bzr init-repo inkscape
$ cd inkscape

===Working locally===

Get Inkscape's code
$ bzr branch lp:inkscape myproject

Now work:
$ cd myproject
... work work work ...
$ bzr commit -m "Some changes"
... more work work work ...
$ bzr commit -m "More changes"
... create new file ...
$ bzr add new-file.c
$ bzr commit -m "Added new file with kittens"

===Advanced local features===

To undo a commit:
$ bzr uncommit
This will leave your working tree in the state it was just before you wrote "bzr commit". This is useful for example if you forgot to add a file, and want to keep a clean revision history. '''This will not work on an Inkscape trunk checkout.'''

Let's say you started from r770, made 200 local commits, but you decided that what you did since r954 is completely wrong. You want to go back to revision 954 and do it differently. Here's one way to do this. First branch locally to preserve your work (maybe later you'll find out there's some way to save it). Then uncommit everything up to r954 and revert.
$ bzr branch myproject myproject-dead-end
$ cd myproject
$ bzr uncommit -r 954
$ bzr revert

Sometimes a big change gets committed while you are working on a feature. If you want to check whether your code still works after the big change, merge from trunk.
$ bzr merge

In this case, you can omit where you are merging from, because the default is to merge from the branch you started from (the parent).

To cherry-pick specific revisions from another branch:
$ bzr merge -r340..360 ''branch_location''
Or to cherry-pick a single revision:
$ bzr merge -c340 ''branch_location''

===Publishing your work on Launchpad===

To publish branches on Launchpad, you have to add an SSH key to your account. If you don't have one yet, generate it:
$ ssh-keygen
... follow instructions ...

Once you created the key, go to your Launchpad profile page, edit SSH keys and paste the contents of the key file (by default it's in <tt>~/.ssh/id_rsa.pub</tt> or <tt>~/.ssh/id_dsa.pub</tt>) into the window. You can now use the Launchpad integration features.

Login to Launchpad, if you didn't do it yet. You only need to do this once on each computer. You need to use your login name, not the display name.
$ bzr launchpad-login johnq

Publish your branch on Launchpad. If you push it under your username, only you will be able to modify it. If you have commit access and publish your branch under the username <tt>inkscape.dev</tt>, all Inkscape developers will be able to change it.
$ bzr push lp:~johnq/inkscape/myproject
$ bzr push lp:~inkscape.dev/inkscape/myproject

The push location will be saved. After more commits, you can simply write
$ bzr push

It's sometimes convenient to update the Launchpad copy after each commit. To save on typing, you can bind your working tree to the remote branch. This way every commit will be immediately published on the remote branch. Note that you won't be able to commit while offline.
$ bzr bind :push

'''Note that it is very helpful if other Inkscape developers can commit to your branch.''' For example, if someone is reviewing your code, it is much easier to make some quick edits than to tell you to make the edits. (for example, Johan will become very angry when he cannot commit small edits, he will stop reviewing right there, and never look at your branch again!)
The easiest way to make your branch commitable to others is to upload it as:

bzr push lp:~inkscape.dev/inkscape/myproject

However, you must be a member of [https://launchpad.net/~inkscape.dev inkscape.dev] (have commit rights) to
do this. If you are not in inkscape.dev, you'll need to create a team
consisting of yourself and the Inkscape Developers group, and upload
as that team. (You can create a team from the front page of
Launchpad.)

===Putting your work in the trunk===

Once your new killer feature you made in a branch is ready, you need to merge your changes into a checkout of the trunk. If you don't have one, do (in the directory ''containing'' myproject):
$ bzr checkout lp:inkscape trunk
$ cd trunk

If you already have one on hand, make sure it's up to date:
$ cd trunk
$ bzr update

Now that you have a local checkout of the current trunk:
$ bzr merge ../myproject
$ bzr commit -m 'added my feature'

Alternatively, if you don't have a checkout but a branch:
$ bzr merge ../myproject
$ bzr commit -m 'added my feature'
$ bzr push

Note that you need to do the above sequence on a branch that has not diverged from the trunk, otherwise it will fail, as the trunk is append-only.

The third method is to merge trunk into your local branch, then push:
$ bzr merge ../trunk
$ bzr commit -m 'added my feature'
$ bzr push

'''WARNING:''' This last method should be avoided if possible. If any work was done in trunk since you branched, all of it will be converted into subrevisions of your merge commit and revision numbers will change. This method will also fail with append-only branches, such as Inkscape's trunk on Launchpad.

====Undoing a wrong-way merge====
:''NOTE: Inkscape and Lib2geom trunks are append-only, so you will be prevented from doing the mistake discussed here, but this information is provided here in case it is useful for other projects.''

Let's say you merged trunk into a feature branch, then pushed that as the new trunk, and this "erased" some revisions. In reality the revisions are still present, but they became subrevisions of the merge commit. To restore the old revision numbers with your merge as the last revision, do this. First, find the revision into which you want to merge the feature changes. This will usually be the second parent of the mangling merge revision.
$ bzr log --show-ids
$ bzr visualise ''(requires bzr-gtk plugin)

Now branch from this revision:
$ bzr branch lp:myproject -r johnq@example.com-20111230042529-0iwskf9kff2xdmzg

Merge your changes the correct way and commit:
$ bzr merge lp:myproject
$ bzr commit

Replace the trunk with the correct version with unmangled history:
$ bzr push --overwrite lp:myproject

You can now convert the fixed local branch into a checkout of your project's trunk:
$ bzr bind :push

===Working with patch files===

If you don't have permission to commit to the trunk, you can bundle your branch's changes into a patch instead:
$ bzr send -o mychanges.patch

To apply patches produced by the above command, just do this:
$ bzr patch somechanges.patch

===Local branching===

Naturally, all this also works locally. For example, when you're in the <tt>inkscape</tt> directory, you can write <tt>bzr branch trunk export-dialog</tt> to create a new branch of the trunk called <tt>export-dialog</tt>, where you'll work only on improving the export dialog. Similarly, you can merge between local branches.

==Using Git-style branches==

Git stores many branches in one directory, and allows you to switch between them. This is also possible in Bazaar. One way is to use native Bazaar facilities, the other is to use the [https://launchpad.net/bzr-colo bzr-colo] plugin. We'll cover the native way, since the plugin has good documentation.

First, create a no-working-trees shared repository. The repo directory can be hidden if you want.
$ bzr init-repo --no-trees .inkscape-repo

Fetch the trunk and any other branches you want into our repository. (You can also push your local branches.)
$ bzr branch lp:inkscape .inkscape-repo/trunk
$ bzr branch lp:inkscape/0.48.x .inkscape-repo/0.48.x
$ bzr push killer-feature .inkscape-repo/killer-feature

Create your working tree by making a lightweight checkout of a desired branch. The <tt>--lightweight</tt> parameter is imp[ortant, otherwise you can run into problems.
$ bzr checkout --lightweight .inkscape-repo/trunk inkscape
$ cd inkscape

If you have an existing checkout of the trunk, use the following command:
$ cd inkscape
$ bzr reconfigure --lightweight-checkout --bind-to ../.inkscape-repo/trunk

Now you can work in the <tt>inkscape</tt> directory like you would on a normal branch. If you want to switch to a different branch, use:
$ bzr switch ../.inkscape-repo/killer-feature

To create a new branch in the repository:
$ bzr switch -b ../.inkscape-repo/killer-feature-2

==Best Practices for Inkscape Project==

===Registering Bugfixes===

Launchpad will automatically link a bug report to a branch and mark it "Fix Available" once somebody commits using the flag --fixes, e.g. (if you fix those two bugs in one commit):
bzr commit --fixes lp:123456 --fixes lp:123457 -m 'patch description'
Then, bugs can be changed automatically from "Fix Available" to "Fix Released"

[http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html#changing-the-state-in-launchpad-while-committing-in-bazaar Read more: "Changing the state in Launchpad while committing in Bazaar"]

===Test branches before committing merges===

Whenever a branch is merged into Inkscape trunk, the automated tests should be run to check for a few potential errors. This is achieved by running the "make check" command after merging (but before committing any changes). See the example below.

===Proper way of merging===

To repeat, don't do something like:
$ bzr branch lp:inkscape myproject
... work ...
$ bzr commit
$ bzr merge # NOOOO!!! We are doomed!
$ bzr push lp:inkscape

It would obfuscate the revision history: trunk commits that happened between the time you branched and the time you pushed would get grouped into one. Additionally, to prevent this obfuscation, Inkscape's trunk is set to append-only, so the above sequence of commands would fail. Do the merge the other way around:

$ bzr branch trunk myproject
$ cd myproject
... work ...
$ bzr commit
$ cd ../trunk
$ bzr merge ../myproject # correct!
$ make check # Run automated testing
$ bzr commit

You'll need a trunk checkout, but the revision history will be much less confusing, and it's useful to have a trunk checkout anyway for minor fixes.

===Fixing a bug in both trunk and a release branch===

This will assume this directory layout:
inkscape
+-trunk
| +-src
| +-...
+-0.48.x
| +-src
| +-...

Fix the bug in trunk and commit it, let's say it will be revision 1234.
Go to the release branch directory, e.g. 0.48.x, and write

$ bzr merge -r 1233..1234 ../trunk

The operation can take a while. Resolve any conflicts, fix any compilation failures, then commit to the release branch, or post the diff to a Launchpad bug report.

==External links==
* [http://doc.bazaar-vcs.org/latest/en/ Bazaar manual]

[[Category:Developer Documentation]]

Extension repository

2013-05-29T13:24:36Z

Shlomif: Correct grammar.

It would be very useful to have a central Internet repository for Inkscape extensions, in a similar manner to Firefox. This way, Inkscape could update installed extensions from the web site, with no need for the user to know if an extension was updated.

== Extensions ==

===[[ExtrudeEffect]]===
Extrude polygons to "3d", also make "string art".

===[http://wiki.colivre.net/Aurium/InkscapeCalendarShellScript InkscapeCalendarShellScript]===
Creating calendars sucks or is impractical if you do not have something that automates the process of putting the days organized in blocks of months for you. To format manually is easy, but this extension can help you on this too Bash script, works for Win32 with Cygwin.

===[http://wiki.colivre.net/Aurium/InkscapeAreaCuter InkscapeAreaCutter]===
For web designers. Slice your site design into .png images. (pt_BR)

===[http://www.julienvitard.eu/ EQTeXSVG]===
Convert an inline LATEX equation into SVG path using Python.

===[http://www.kono.cis.iwate-u.ac.jp/~arakit/inkscape/inklatex.html InkLaTeX]===
Insert LaTeX text or equations into Inkscape.

===[http://www.iki.fi/pav/software/textext/ TexText]===
Embed re-editable LaTeX objects into SVG drawings.

===[http://math.univ-lille1.fr/~barraud/Inkscape/pathdeform/ PathDeform]===
Bend a path according to another one.
N.B. This extension was added to Inkscape 0.45 as "Pattern along Path".

===[http://www.inkbar.lineaire.net/ InkBar]===
Create EAN13 bar codes.

===[http://technoargia.free.fr/swftools/ SWF output]===
Save drawings as SWF.

===[http://wiki.colivre.net/Aurium/Puff Puff]===
Fluffs elements! :D

===[http://www.colivre.coop.br/Aurium/InkSudoku Sudoku Generator]===
Generates a Sudoku square with its solution (''in a small square if you want'').

===[[CalligraphedOutlineFill]]===
Helps to fill in the inside area of shapes drawn with the Calligraphy tool.

===[http://edlab.die.unipd.it/Site4.html SlotStar]===
Helps to draw the star of slot of a winding of an electrical machine

===[http://richard.henwood.googlepages.com/inkscapelatexextension inkscapeLatexExtension]===
Extract text in an SVG drawing to a LaTeX picture environment.

===[http://saws.googlecode.com s.a.w.s]===
Export an SVG as valid XHTML/CSS files.

===[http://www.colivre.coop.br/Aurium/InkscapeGenerator Generator]===
Replace text and data to automatically generate files (as PDF, PS, JPG, etc...), based on an SVG template and a data file. eg a CSV file

===[http://code.google.com/p/inkscape2tikz/ TikZ exporter]===
Export SVG paths as TikZ/PGF code for use with LaTeX.

===[[FindMatch]]===
Looks for paths that match the selected path and places all matches on the same layer.

===[http://xico.freeshell.org InkSyntax]===
A source code syntax highlighter plugin for Inkscape (wrapping [http://www.pygments.org pygments] and [http://www.andre-simon.de/doku/highlight/en/highlight.html highlight]).

===[http://sites.google.com/site/placeonpath/ Place Objects on Path]===
Places objects on a curve. The curve is the object that has the lowest z-order (and which must be a path). Distances between objects remain the same as they were before placing. If objects can't be placed on the curve because of their distances they are left in place. Objects will not be modified; clones are allowed. Arrange distances between your objects manually first as curve position and direction.

===[http://code.google.com/p/jessyink/ JessyInk]===
A collection of Javascripts that can be embedded into an SVG file to produce slide shows on opening in a browser. Current releases of JessyInk include a number of inkscape extensions to assign effects, transitions and other aspects of the presentations.

===[http://svg2dxf.googlecode.com/files/svg2dxf_inkscape.zip svg2dxf]===
Updated version of [http://www.bobcookdev.com/inkscape/inkscape-dxf.html Better Better DXF output] which adds support for polylines and does not overwrite the default inkscape simpletransform.py. See README if getting lxml xpath errors.

===[http://code.google.com/p/pixelsnap/ PixelSnap]===
Tool for aligning object/paths onto the pixel grid for bitmap export.

===[http://code.google.com/p/inkscape-guides-creator/ Guide creator]===
Creates multiple guides at once, at set intervals.

===[http://code.google.com/p/inkscapescalegenerator/ Scale Generator]===
Create ruler scales / map scales.

===[http://code.google.com/p/scott-inkscape/wiki/SevenSegmentDigits Seven Segment Digits]===
Create calculator style digits.

===[http://www.cnc-club.ru/forum/viewtopic.php?f=15&t=37&p=92 Close curves]===
Closes all open paths in the selection.

===[http://www.cnc-club.ru/forum/viewtopic.php?f=15&p=101 Gcode tools]===
Generates Gcode program (used in CNC machinery) from given paths.

===[http://dp48069596.lolipop.jp/inkscape_script.html Closeoff, Scatterpath, Selection, Zigzag and Netting]===
See [http://dp48069596.lolipop.jp/inkscape_video.html] for how to use Zigzag and scater extensions.

===[http://wiki.xmoto.tuxfamily.org/index.php?title=How_to_create_smooth_levels_using_Inkscape Inksmoto]===
Level editor for the Xmoto game.

===[http://www.cnc-club.ru/forum/viewtopic.php?f=33&t=37 Close Curves]===
Extension to close the paths in the selection, useful for importing filled paths into openoffice.

===[http://kalyaev.com/2010/20100423/gcodetools.html gcodetools]===
Gcodetools is a plug-in for Inkscape. It prepares and converts paths from Inkscape to Gcode, using biarc interpolation. for use with CNC milling machines.

===[http://www.signcutpro.com/SignCut-Productivity-Pro/signcut-export-plugins.html SignCut Export]===
Set of extensions that come with SignCut to enable Inkscape users to use plotters / cutters via the SignCut software.

===[http://www.lysator.liu.se/~perni/iboardgameexts/ Boardgame extensions]===
Inkscape Extensions for Boardgame Developlemt [http://www.boardgamegeek.com/thread/299033/inkscape-extensions-for-boardgame-developlemt 1]. Includes a hexagonal board/hexmap creator and tools to sheets of tiles for counters ect.

===[http://camm-gl.dyndns.org/ Inkscape CAMM-GL Extension]===
... vinyl cutting utility for Inkscape

This program is basically just a cut manager. Create artwork in Inkscape, save with the supplied hpgl_output extension, and cut or plot with this program. The program does provide some useful functions, but it is by no means a fully featured solution. I do use it exclusivly, and it currently satisfies my needs.

===[http://salug.it/~fabioviola/inkscape/extensions Badge Renderer]===
... A little script to render a badge in a Inkscape document.
This is only a little python script used as example in an article for my GLUG (SaLUG!) journal. This can be used to quickly render a badge. It can be improved, for example, with shadow direction and reflex direction. As soon as possible I'll do it.

===[http://www.craigmarshall.org/archives/8 Guillotine]===
This is a mirror of the GIMP guillotine function, it allows you to drag guides onto the canvas, and then using Export->Guillotine, export those slices as pngs to the directory and filename of your choice. It also has an option for using export hints, if your drawing has previously been exported. [http://www.inkscapeforum.com/viewtopic.php?f=11&t=5832 Forum link]

===[http://code.google.com/p/inkscape-replace-font/ Replace Font]===
Allows mass replacement of the fonts in a document. Can list existing fonts. [http://www.inkscapeforum.com/viewtopic.php?f=11&t=5843 Forum link]

=== [http://sozi.baierouge.fr/wiki/doku.php?id=en:welcome Sozi] ===
A tool for presentations made using zooms and rotations, not just slides. Uses Javascript added to the .svg file to display in web-browsers

===[http://www.inkscapeforum.com/viewtopic.php?f=11&t=5943 CMYK pdf/tiff export]===
Extension to export to CYMK colourspaced PDFs / Tiffs. In development (september 2010)

===[http://sourceforge.net/projects/o-scape/ O-Scape; Orienteering map making tools]===
Extensions to help make Orienteering maps; see this [http://www.nopesport.com/news/1343-o-scape-free-orienteering-mapping-software interview] for more information

===[http://www.inkscapeforum.com/viewtopic.php?f=5&t=4729#p32019 Mirror]===
Mirror a path along any axis.

===[http://sourceforge.net/projects/inkscape-tables/ Tables in Inkscape]===
Adds (experimental?) table suport as an extension.

===[http://doctormo.org/2011/05/19/deviantart-plugins-released/ deviantArt uploaders]===
Upload artwork to deviantArt from the "publish to" menue item under extensions.

===[http://code.google.com/p/inkscape-music-scale-generator/ Musical scales]===
Extension for automatic generation schemes of musical scale and chords on piano.

===[http://www.inkscapeforum.com/viewtopic.php?f=11&t=9212 Text from CSV]===
Extension to enter text from a CSV file

===[http://luther.ceplovi.cz/git/inkscape-ungroup-deep.git/ Deep Ungroup]===
Ungroup all groups in the selected object.

===[http://www.pernsteiner.org/inkscape/layerclip/ Layer Clip]===
This is a a set of Inkscape extension scripts for setting and removing clip paths for entire layers. Inkscape has no trouble rendering or editing layers with clip paths, but it currently has no built-in method of setting the clip path for a layer, this is the purpose of these extensions.

Features include: Clip containing layer, Clip layer above, Clip layer below, Clip parent layer.

'''''Notes:'''
''You must select an object in the clipping layer before applying the extension, otherwise you will receive an error message.
It is a good idea to lock the layer after the extension has been applied. You may also require hiding the clipping layer when using "Clip layer below". This may be exploited to create a masking layer.
Tested on Inkscape 0.48.2 r98''19''

===[https://bitbucket.org/daviddamerell/inkscapesaveasicoextension Icon Generation]===
This is an Inkscape output extension that adds an option to the "save-as" dialog box to generate Windows Icon files (*.ico).

==Extensions for Programmers:==
===[http://wiki.colivre.net/Aurium/RubyInk RubyInk]===
Inkscape extension with Ruby

===[http://wiki.colivre.net/Aurium/InkBash Ink-Bash]===
<nowiki>ShellScript</nowiki> Forever!

===[http://wiki.colivre.net/Aurium/InkMoz InkMoz]===
The Bridge from Inkscape to Mozilla (Inkscape extension with Javascript and more)

== The Repository Specification ==

A website where programmers can publish their extensions, users can search by that, and an update program can access this updates.

=== The Website ===

Must Have:
* '''User Registration''': to allow upload, votes and comments
* '''Extension Validation''': when published, it is public, but the user must be notified that was not validated (the code must be viewed by an validator user). The software updater do not update non-validated versions.
** '''Validation Feedback''': the validator user must write why the extension was not validated.
** '''Extension Deletion''': the validator user can delete an extension or version when he found a malicious code. The upload user must be marked as a malicious user and the account must be blocked.
* '''Extension Search''': with filter, by any available data.
* '''User Votes and Comments for Extensions''': The user can vote and/or comment an extension version.
* '''Extension Bug-Tracker''': today, third part extensions are in simple web-pages. The site may have a Bug-Traker to help all little scripts.
* '''User Extensions Requests''': a lot of users have ideas. Here is a good place for programmers see and make that alive.
* '''Host a cool page for the extension''': allow introduction text, documenbtation, screenshots, examples, and '''i18n'''!
* '''Help the l10n of this extensions''': with a web interface, like pootle and provide the l10n file for the updater program.
* '''Provide Version Control''': A SVN account will be cool, but web uploads (by web-forms) can be transparently SVN commits.

=== The Extension Meta-Data ===

''The data in INX file and more some, like the OS and Inkscape version compatibility...''

The INX file will define the meta-data settable by that. If some extension uses multiples INX files to have more than one option in the menu, all INX files must be read to set the meta-data. The meta-data will be cached in a database to help the search. The DB only need the meta-data of the last validated version and the last non-validated (if that is newer).

=== The Update Program ===

* '''Search for New Extensions''': when the user request
* '''Update Extensions''': search for updates and install that
* '''Help the Code Validation''': for advanced users. Show the extension code and the diff if is that an update.
* '''Help the User Bug-Reporting''': that is not working! The user must say now! ''(When the Update Program be part of the Inkscape, the error window can have a button to submit a bug-report)''
* '''Must test the extension dependencies''': the user must know what is needed to install before try to use.

== Name Proposal ==

Propose a name for the Inkscape Extension Repository:

* '''The Factory'''
* '''Extension Factory'''
* '''INX Factory'''

''Why Factory? Because it is not only a repository. ;-)''

* '''The Furnace'''
''Because Fire & Coal (Passion & Knowledge) are your tools for creating the extensions''

[[Category:Developer Documentation]]
[[Category:Extensions]]

== Mockups ==

Here are some suggestions for what an extension repository might look like.

<gallery>
File:Extension_repository_-_homepage.png|The home page.
File:Extension_repository_-_extension_page.png|The page for an individual extension.
File:Extension_repository_-_request_page.png|The page for an individual request.
File:Extension_repository_-_search_page.png|The search form page.
File:Extension_repository_-_search_results.png|The search results page.
File:Extension_repository_-_submit_extension.png|The extension submission page.
File:Extension_repository_-_submit_request.png|The request submission page.
File:Extension_repository_-_requests.png|The main requests page.
</gallery>

I have no idea of the detail of this project; I don't currently have the skills necessary to try implementing it. I'm also not sure whether it's a good idea for Inkscape to offer hosted repositories (using [http://www.redmine.org/projects/redmine Redmine] or [http://trac.edgewall.org/ Trac]?) or whether it would be better to just leave it to the developer to use somewhere like [http://github.com/ GitHub] or [http://bitbucket.org/ BitBucket] and then use their APIs to pull some basic data onto the site. [[User:Legio noctis|Legio noctis]] 10:19, 23 May 2010 (UTC)