Inkscape Wiki - User contributions [en]

User:Ciradrak

2025-06-18T20:41:07Z

Ciradrak:

I like to use Inkscape.
I used it to do most of my drawings for school.

I love the elegance of Inkscape and prefer it's node display and editing mechanism greatly over Illustrator's. And frankly, Inkscape is now so mature that I don't really see the point of attempting to follow what any other program does. It is now its own thing and must forge ahead to find its own path.

Developer manual

2010-05-04T05:42:50Z

Ciradrak: garbage collection, caveats, added possible year to date, as june 7 2010 is coming...

= Inkscape Developer's Manual =

== Introduction ==

For those of you just joining us, or who have been with us but are just
now getting the itch to work on Inkscape, I thought I'd give some tips
for how to get started working in the codebase based on our own
experiences.

One of the first things most people wonder is "what should I work on".
As you may have already noticed, we generally don't "assign" projects.
We figure there's plenty more work to do than people to do it, so you
may as well work on something that you're either interested in or that
adds something of benefit to you; that's extra motivation to get your
own itches scratched.

If you're really stumped though, we keep a detailed [[Roadmap]] in wiki that
you're welcome to browse through to look for ideas of things to work
on. Tasks that do not have names beside them are open for anyone to
take; if you want to take ownership of a task, just put your name beside
it. Feel free to add or reword tasks as needed, although try not to
load up the current milestone with tasks that aren't critical for the
release. Feel free to work on stuff that is several milestones down the
road; there's rarely any problem with getting stuff done sooner than
planned. ;-)

We have a process for gaining SVN commit access. The reason is that
while it is important that we keep access to the codebase open, we don't
want to be crazy and leave it wide open to any random passer-by. The
process is that we require that the person make two contributions
(patches, documentation, web collateral, etc.) and then make a request
to get account access.

In general you won't need SVN commit access in order to start doing
development, because you can work from an anonymous checkout and create
patches. If you've not done this before, you'll need to learn this
skill first (basically see docs for `svn diff`).

When you first start hacking on Inkscape code, I wouldn't recommend
taking an objective of implementing a specific feature, because you will
need some time to familiarize yourself with the codebase, and because
you won't really know what features are going to be straightforward to
implement and which will be highly challenging. Of course, if you have
the time and love adventures, this might be a fun way to go.

There are four approaches that I've seen people effectively use in
getting into the codebase:

<ul>
<li>Write code documentation. Some people who don't mind adding
comments to code or writing docs find it useful to just go through
code they're interested in working on and writing up what it does.
The codebase is in dire need of better docs, so this approach pays
dividends well into the future.
</li>

<li>Fix bugs. Tracing down the cause of reported bugs is an effective
way to gain understanding of the codebase in small chunks. Many
common bugs can be traced down and fixed in a matter of hours, and
often will identify some bit of code in need of refactoring or
extension. Note that some of our older bugs are in the system
because they're hard to fix, so you'll want to work on the more
recent ones.
</li>

<li>Chip in on a group effort. Occasionally we identify a major
refactoring effort (such as when we converted from C to C++), that
we encourage lots of people to help on, in the philosophy that many
hands makes short work. This work tends to be pretty rote so is
not hard for new folks to get involved with; it just takes time. We
generally have one of these kinds of efforts per release. It
usually isn't glamorous work, but in aggregate moves the codebase
forward in a major way.
</li>

<li>Subsystem/module work. Some people want to get their hands in the
details quick, so take the approach of developing new code separate
from the codebase, to be integrated in later. This generally tends
to take a larger time commitment than the other approaches, but can be
an effective approach in some circumstances. We have a SVN module
called 'experimental' that you're welcome to house your work until
it's ready for prime time.
</li>
</ul>

Beyond that, you're going to find the documentation for the Inkscape
code is pretty scarce. We've worked on bits and pieces but
unfortunately the vast majority of the code is undocumented. On the
plus side, often you can implement the stuff you care about after
learning only a limited portion of the codebase.

I think you'd find Inkscape an enjoyable Open Source project to work on.
There's a huge range of interesting and useful skills that can be
learned from it, plus the developers are great guys to participate with.
The project itself runs smoothly and puts a premium on keeping things
friendly and low-stress, so heated arguments are rare. The users have
been great to work with and very appreciative of even small new features
and fixes. Plus, since Inkscape is so visual in nature, it's very cool
to see how your little changes make noticeable improvements to the app
overall.

== C++ Reference ==
* FAQ (with answers) sheet. We strongly recommend that everyone read this site comprehensively. You should not need to bookmark it, it should be the first of the sites on your autocomplete list for <code>par</code>!

http://www.parashift.com/c++-faq-lite/

It is actually more in-depth than the name FAQ suggests. Many experienced C++ programmers would benefit from it.

* List of [http://www.cs.helsinki.fi/u/vkarvone/2004s/cplusplus/errors.html schoolboy errors]. None of these should appear in [http://en.wikipedia.org/wiki/Free/Libre/Open-Source_Software FLOSS] code.

== Strings ==
Please make sure any user-visible strings are localizable. This requires wrapping them with "_(" and ")", like so:

"Select object"
becomes
_("Select object")

In case the interpretation of the string may be ambiguous or may differ according to context, you can add a context prefix (that won't be displayed) in order to eliminate the ambiguity.
"Ambiguous string"
can then become
Q_("Context|Ambiguous string")

For more complex things, please check the gettext/localization documentation.
See also http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html

== Implementing User Interface Changes ==

UI improvements are enjoyable to work on because they produce visible changes in how Inkscape works. These improvements are one of the most tangible ways to help improve how Inkscape works; thus, we strongly support new developers wishing to work in these areas.

It is also very important to us that Inkscape presents an organized, productive, and easily discoverable interface to users, and because of this it is important that new Inkscape UI developers work to ensure changes make Inkscape's UI *more* consistent, *more* flexible, *more* cohesive, and so on. We don't have firm rules about what can and cannot done, so as to ensure there is plenty of freedom for innovation. However, we can outline some general principles and guidelines that are important to keep in mind:

'''Don't please the artist - BE the artist''' - Many times UI is designed and created by programmers who "understand what the user wants". But in Inkscape we believe that the best requirements list is the list inside the user's head. Requirements docs, usability studies, and so on are very indirect ways of transferring this gut-level understanding from user to programmer. We believe the best way to ensure this information is communicated clearly is for the user to BE the programmer. Or, alternatively, for the programmer to BECOME a user.

This is why we so strongly encourage users to get involved in coding, and why we so strongly encourage programmers to focus on the features that are most important to them personally. This is also why it is absolutely critical to pay close attention to what users report when using a new feature - often they can tip you off to alternate designs that achieve the same result in a better way.

'''Eliminate limitations''' - Commercial software is often developed to fulfill feature requirement lists from a marketing department. As such, it's common to see the feature implemented to meet the requirement exactly, and no more. However, especially with artistic software, art is often found outside what seems reasonable. So when putting in a new feature, avoid the temptation to limit it to what you expect people to use it for - instead generalize it and open as many parameters as possible for tweaking, and let the artist decide what is reasonable - that is their job.

As an example, a drawing program might want to support the features, feather and drop shadow. Obviously, users need these important features. Commercial software may well implement these as distinct features, each with their own UI controls. However, these features are just special cases of the more general gaussian blur, and in Inkscape we implemented *that*. With that in place, artists can not only do feathering and blur, but a whole variety of other effects.

It is interesting to note that, as an open collaborative standard, SVG
necessarily has the same goals as Inkscape: a minimum set of
universal, well thought-out building blocks that can accommodate the
widest possible range of graphics and applications. Thus, simply by
following the SVG philosophy, Inkscape scores quite a few important
points over commercial software. Live clones, patterns that can be contain any
objects, layers that are essentially groups and can be easily
converted to/from groups - all these are examples where the underlying
universality of SVG directly translates into extremely valuable user
features.

== Implementing New SVG Features ==

The most important way to help Inkscape is to implement a new SVG feature in it. Our hope is to eventually support ALL SVG features, so if you can help check one off the list, it brings us close to the nirvana of 100% SVG compliance. :-)

Generally we find that implementation of an SVG feature goes through three discrete stages:

1. Find the appropriate tags and attributes in the SVG spec
2. Implement support for rendering files with these tags
3. Implement support for UI controls to edit the tags

(1) is mostly a research project. Start by reading the SVG spec so you
can learn about the tag, the attributes that go with it, and so forth.
It is good practice to set up a page in the Wiki for storing your notes
as you do this process, so that in case you don't make it to steps 2 and
3, then maybe someone else can benefit from your research.

(2) is the fun part. It helps to be comfortable with Inkscape internals
for this part. Depending on the feature, it may require advanced
knowledge of transformation, rendering, document management, and so on.
For this part, just hand-edit an SVG file to put the tags in that you
found in step #1, and keep plugging away at the code until Inkscape
displays things as the specification dictates. It can help to compare
your work with Batik, as we use that program as our reference
implementation.

(3) is the most important stage, since it is the point at which the
feature becomes available for users. This step often requires knowledge
of Gtk+, for creating dialogs, widgets, menus, etc. for allowing the
user to edit the characteristics of the feature. Be sure to listen to
feedback from other developers and users - especially if there are
different opinions. It is hard to come up with UI that everyone can
agree on, but it is worth the work to achieve this - the more critique
your UI survives, the better loved the feature will be for future users.

Looking through Inkscape's history, these stages are often done by different people. If you're new to Inkscape, you may find working on stages 1 and 3 easiest, but there are many developers who can answer questions when you're ready to dig into the internals, so don't be afraid to ask questions!

== Standards Compliance - Extension Namespaces ==

* Only elements and attributes from our extension namespaces that ''do not affect rendering'' may be saved in SVG documents.
* Generally, this means that extension elements and attributes should only be used to provide UI hints.
* Extension elements and attributes should ''only'' be used where an existing facility provided by XML or SVG is not sufficient.

== Global Verbs ==

Here's a readers' digest summary of how Inkscape accelerators work:

A global mapping between key combinations and integer verb IDs
(sp_verb_t) is maintained in shortcuts.cpp; these are registered using
sp_shortcut_set().

Given an sp_verb_t and an SPView, you can get an SPAction which
represents that action in that view. These mappings are currently
hard-coded in verbs.cpp.

SPActions derive from NRActiveObject, which putatively provides a
"lightweight" method of doing callbacks, versus GObject signals. I
don't completely understand how it works.

SPActions also contain the label, image, etc, used for buttons and
menuitems.

sp_shortcut_invoke() looks up the SPAction for a keypress and SPView and
invokes it automatically. SPEventContexts call it for keypresses that
they do not handle themselves.

== Garbage collection ==

As you know, many automatic garbage collectors (like libgc) only
free and recycle memory periodically. This means you may have some
extra slush that could be freed, but hasn't yet.

There are other forces at work, though...

Pretty much all allocators, whether automatic or not, whether the
system malloc() or some custom allocator like libgc's, work the
same way: they request large blocks of memory from the operating
system, then divvy those blocks into smaller ones internally to
satisfy application allocation requests.

When an application frees memory, that memory is usually recycled
internally rather than returned to the OS immediately. The reason
for this is that the large memory blocks acquired from the OS must
be completely unused before they can actually be freed.

Let's say for example that an allocator acquires 16 8MB blocks from
the OS in response to 32768 4k application allocations...

In a worst-case scenario, it's possible that the application could
free 32752 of those 4k blocks but the remaining 16 4k just happen
to be distributed across the 16 8MB blocks requested from the OS.

If that happens, from the application's point of view it may only
have 64k allocated, but as far as the OS is concerned, it's still
using 128MB!

Note that this applies to nearly all allocators in common use.

While it's unusual for things to get quite that bad, memory
fragmentation is common enough that many popular allocators (for
example Perl's) simply don't bother trying to return memory to the
OS at all (the memory will still get forcibly reclaimed by the OS
when the process exits).

[ FWIW, libgc's allocator is one of the ones that _does_ make an
effort to release memory to the OS, but it is limited by
fragmentation like any other ]

Also note that for various reasons, the statistics you get from the
OS aren't going to directly reflect the amount of heap-allocated
memory. Be careful drawing conclusions from only looking at e.g.
the output of top(1)...

(the worst thing is that due to the modern practice of
overcommitting memory, the OS may literally lie to an application
about the amount of memory it is being given, hoping the
application won't really try to use it all)

The best approach to evaluating memory usage is if you can ask the
allocator for information on memory usage directly, as that matches
the world from the point of view of the application.

leftover gradients/markers/patterns
will get automatically cleaned up when the objects that use them are
deleted.

Caveats:

* this only applies to such objects created with a build of Inkscape which post-dates this commit (June 7) (2009?)

* not all automatically-created objects will necessarily be collected; the code that creates them needs to be updated to set the correct collection policy

* paint objects won't get collected until another editing operation takes place, since NRArenaShape currently holds onto an SPStyle for too long

Technical details:

Assuming its collection policy permits it, an object will be collected
if neither it nor its descendants have any outstanding inter-document
URI references (nonzero SPObject::hrefcount).

There are two "policies" for collecting orphans:

* "with-parent" - the object will only be collected if one of its ancestors is collected

* "always" - the object is always collected if unused

(a third policy might be "never", which would necessarily also prevent
that object's ancestors from ever being collected; I do not plan on
implementing it)

The policy in effect is determined by the inkscape:collect attribute.

Be careful with the "always" policy; it really only makes sense for
"private" objects that are indirectly created behind the scenes (e.g. by
selecting a fill or marker option in the GUI).

SPDocument manages a queue of objects to collect; SPObject handles the machinery for actually queueing them when their hrefcount falls (based on policy), and performing the actual collection (delete).
SPDocument::collectObjects() performs a collection pass; it's currently only called from sp_document_maybe_done().

== Inkscape Experimental SVN ==

The 'experimental' module in Inkscape SVN is provided as a kind of "scratchpad" for
working up new ideas that aren't quite ready for folding into the main codebase.
This includes architectural sketches, examples, experimental patchsets, tools & utilities, or
whatever else strikes the developer's fancy.

Please create a subdirectory within experimental/ for your work. You're welcome to either post
the stuff at the top level or create a subdirectory for yourself. Things linked in at the top level
should be considered fair game for other developers to collaborate on; items posted under
a developer's username should be considered ask-first. Same sort of idea as wiki.

One of the principles behind this module is the idea of a shared working space. Other developers
working in experimental can fairly easily see what others are working on in the tree, and perhaps
borrow or contribute ideas back and forth. Since it is by definition not 'production' code, the
work may be incomplete or in a non-compileable state, and thats O-K.

When an experiment has matured to the point of being actually useful, please move it out of
the experimental module to someplace more appropriate. Or alternatively if the experimental
work has become obsolete or irrelevant, please remove it so we can avoid having the
experimental tree get too bulky.

== Directory Organization ==

=== Distribution / Packaging Files ===

Files related to generation of distribution packages should go under inkscape/packaging, as follows:

inkscape/packaging/
common/
debian/
fedora/
fink/
mandrake/
suse/

=== "Share" Collateral ===

A variety of items are installed in addition to the program itself, and placed into a 'share' directory structured as follows:

AUTHORS
NEWS
clipart/
examples/
extensions/
fonts/
gradients/
icons/
keyboards/
markers/
palettes/
patterns/
screens/
about.svg
templates/
tutorials/

In the SVN codebase, all of these are placed in inkscape/share/ (except AUTHORS and NEWS which will be copied to share during installation. The idea is that in theory, this entire tree structure can be copied into place on the user's machine.

However, we need to provide the user some level of control over the installation. They may wish to exclude some items, or may wish to augment the default install with some items external to the Inkscape package. For example, they may wish to incorporate external clipart collections. One approach would be to install symlinks in the given component directory to the external collection. For example, if the flags package were to install into /usr/share/flags-svg/, we'd just symlink there.

=== Code modules ===
Several parts of the code were written in a modular way, and they have been
accordingly placed in subdirectories of src/, while the main src directory
still contains the biggest part. To get a first overview of the modules, you
might want to have a look at these dependency graphs before you read deeper
into the source code (outside at the moment):

[http://www.ark.in-berlin.de/gri-debug.svgz]
[http://www.ark.in-berlin.de/gri-dialogs.svgz]
[http://www.ark.in-berlin.de/gri-display.svgz]
[http://www.ark.in-berlin.de/gri-io.svgz]
[http://www.ark.in-berlin.de/gri-libcroco.svgz]
[http://www.ark.in-berlin.de/gri-libnr.svgz]
[http://www.ark.in-berlin.de/gri-libnrtype.svgz]
[http://www.ark.in-berlin.de/gri-livarot.svgz]
[http://www.ark.in-berlin.de/gri-widgets.svgz]
[http://www.ark.in-berlin.de/gri-xml.svgz]

These are not all modules! For questions about how to generate these graphs
with graph-includes, please [mailto:rwst@users.sf.net].

Question on .svgz files: Is the server sending the right 'Content-Encoding:' header?
This matters to Mozilla browsers in standards compliance mode! http://jwatt.org/svg/authoring/#server-configuration

= See Also =
* [[DirectoryReorgProposal]]
* [[InkscapeJanitors]]
* [[CompilingInkscape]]

= Links =
[http://advogato.org/article/51.html Software Quality]

[[Category:Developer Documentation]]

User:Ciradrak

2010-05-02T22:23:08Z

Ciradrak: inital brief about me

My background is in video compression and OpenGL.
I was a SodiPodi user and switched to Inkscape
shortly after the fork. I have used, and continue to use Illustrator
and a variety of [http://dracoquies.us/cira/home/cad/cad.html CAD] systems for vector editing purposes and simply to ponder their workings.
Currently I use Inkscape to do most of my drawings for school.

I have my own page about Inkscape at
[http://dracoquies.us/cira/comp/inkscape/inkscape.html http://dracoquies.us/cira/comp/inkscape/inkscape.html]

I love the elegance of Inkscape and prefer it's node display and editing mechanism greatly over Illustrator's. And frankly, Inkscape is now so mature that I don't really see the point of attempting to follow what any other program does. It is now its own thing and must forge ahead to find its own path.

SpecGuidesImprovement

2010-04-27T15:48:52Z

Ciradrak: idea: spacebar to duplicate guides during a drag operation

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/guides-improvement

== Summary ==

This specs provides a comprehensive way of managing guides and guidesets (which are groups of guides).

== Release Note ==
== Rationale ==
Guides are one of the stronger workhorses of any vector editing application. Inkscape has a powerful set of options but I feel the way to manage guides is mainly focused on a per-guide basis and has lagged a bit behind the overall quality of the software. My points for this argument are:
* The current dialog for manually setting guides properties is not as good as it should be since it tops the main window and the user has to pop-up the guides dialog for every editing, breaking the workflow. Also, is inconsistent with the way dock tabs work (much less obstructive).
* The user can't change the color on a per-guide basis.
* This spec adds basic managing operations such as add, remove, copy, visible/invisible and lock/unlock for guides.
** Lock /unlock lets the user specify if the guides should be selectable along the objects or not.
* It also deploys a complete UI framework for fitting the current types of guides (horizontal, vertical and angled) and adding other types of guides (see [https://blueprints.launchpad.net/inkscape/+spec/composition-guides composition guides], or others to come).
* This spec introduces the concept of a '''Guideset''' (or just '''Set'''). This is a bunch of guides that are grouped, having common managing options (copy, delete, visible/invisible, move and rotate).
** If the user selects a set, all of the guides inside it are edited homogeneously.
** Sets allows the user to arrange his guides in a comprehensive way (specially important when there are dozens of guides on the document).
* Right now, for angled guides, the user can edit the angle and center of the guide numerically but not on-canvas. I try to improve this too.

== Design ==
=== UI ===
Pretty self-explanatory...

[[Image:Guides-mockup.png|left]]

The guides shown inside the viewer contains from left to right: visible/invisible, ID (name), and icon for type.

Using the drop-down menu we can select the type of composition guide:

[[Image:Guides_selector.png]]

=== On-canvas editing ===
The guides can be edited on canvas with only mouse and some key modifiers. These modifiers try to mimic the current behavior when transforming objects (the first three actions are already implemented).

[[Image:Guide_editing_mockup.png]]

The rotation can be snapped as any other node to grids or other guides.

=== Usage ===
* The IDs of the newly created guides should have more meaningful names like ''guide001'', ''guide002'', ''guide003'', etc. More appropriate would be to have the names being "smart", i.e.: the name has some resemblance to the name of the guideset it is attached to. So if you have a guideset called ''left eye'' the guides are named ''left eye001'', ''left eye002'', etc. A guideset called ''right eye'' would have guides named ''right eye001'', ''right eye 002'', etc.

* '''How does lock/unlock work?''':
** A ''locked guide'' can be moved and rotated on-canvas the same as an ''unlocked guide''. However, the ''un''locked one '''is selectable along the objects''' with the selector tool (both dragging a square and touch selection), '''and moving and rotating the object does the same for the guides'''.

* '''Guidesets:'''
** This is an usage example: imagine you are working on the design of a complex drawing such as a book cover or a product label, you will end with many elements on the page: text, vector figures, lines, bitmaps... and grids, lots of grids. Till now, the guides are hard hard to tell apart when there are a lot of them. However, is quite probably that you can break them into groups so you would have '''sets''' and '''guides''' such as:
*** ''text guides''
**** ''main title''
**** ''subtitle''
**** ''name of the author''
*** ''barcode and copyright''
**** ''barcode bound1''
**** ''barcode bound2''
**** ''barcode bound3''
**** ''barcode bound4''
**** ''copyright text''
*** ''cover design''
**** ''guide1''
**** ''guideN''

Thus, and using different colors, the layout of the grids should be clearer and more usable.

=== SVG representation ===

== TODO ==

== Discussion ==
I'm unsure about these ideas. Please, discuss below.

* IDEA: Add '''snap''' option for every guide or every set, so the user is able to decide if snappable elements should snap to it or not.
* IDEA: Add '''attach''' option so a guide or guideset can be attached to an object, so selecting and transforming the object automatically moves and transforms the guides.

* REMINDER: '''Lock/unlock''' feature requires guides '''to be selectable along the objects''' (which I don't think they are right now). This is aimed to future developers.

* IDEA: Currently if a double click is done at the intersection of a guide and a path (being node edited) the guide will get the double click (0.46, 0.47). This means a user cannot use the double click to add a node to a path at the intersection of a guide and a path. My work style, and the style of some others, is to use the guide to place nodes but the guide gets the higher priority. To me, I would rather see the guide getting a lower priority for the double click so the path being node edited will create a new node. If guides were locked would the double click be ignored by the guide and allow the path to add a node? - Lawrence

* IDEA: Should guides be shapes on just another layer? The layer could be locked / unlocked the way other layers are currently being done. - Lawrence

* IDEA: When dragging an object currently in Inkscape pressing the spacebar will drop a copy in the current position. It would be great to do the same thing with guides as an easy way to create copies.

Inkscape popularity

2010-02-15T01:28:14Z

Ciradrak:

== Idea ==

The idea of this is mostly about helping Inkscape and other open-source apps being more popular in the professional and academic graphic design world.

The needed is getting help from arts/design and engineering universities, associations (like http://www.icograda.org), design-related studios, offset printing companies, etc., the most worldwidely as possible.

Getting contact from both arts/design and engineering worlds would provide us to get the best features and intensive testing (specially on the speed and accuracy we need from this kind of application)

What also would help on Inkcape popularity is making it more visible from graphic design related magazines, like Eye (http://www.eyemagazine.com/), Communication Arts (http://www.commarts.com/), U&LC (http://www.uandlc.com/), Emigre (http://www.emigre.com/), [[DotDotDot]], etc.

Comments and helps on this task is hugely welcome!

How to attract graphic design professionals: Prioritise the UI

* Clarity and usability. If Freehand and Illustrator do things a certain way in terms of layout or terminology then so should Inkscape - unless it is seriously sub-optimal.

::I agree, except that Illustrator ways are indeed often suboptimal, especially in the context of Inkscape. Anyway, please make specific proposals. --bb

* The default keyboard shortcuts should be the same as the industry leaders. Reduce clutter and look at the UI trends Adobe are pushing. They have a lot of historical baggage to accomodate which Inkscape doesn't so we can get there quicker and cleaner. Another point.

::See my comment in your RFE on this. --bb

As an Architecture student I use Inkscape specifically because its interface for control point editing is *better* than Illustrator's. I would never want to see Inkscape become a 'follow the crowd' project. We can look to programs like Illustrator, Xara, CorelDraw, and even CAD systems for inspiration; but never imitate a function wholesale unless that aspect really is perfect. (And I can't think of one of them which is.) I would rather see Inkscape become a leader rather than a follower.

To make Inkscape more palatable to my fellow students I would say improve its reliability, and the performance of complex files. Focusing on core functionality, and fixing the rough edges -- stuff that doesn't work 'out of the box' -- would also help with adoption. (alt-keys anyone? relative links for embedded files?) Remember that more that half of them are using OSX and the others, Windows. Out of 200-300 students I'm the only one using Linux.
--[[User:Ciradrak|Ciradrak]] 01:28, 15 February 2010 (UTC)

(I'll eventually edit this rant and move it to a more appropriate place.)

::*Tutorial videos?
::*Get Inkscape used for some major/important public art and publicise this?
::*Prioritise the text editing tools so that they are more conducive to newbies who have been coaxed into straying from Microsoft Word's wonderful :( poster-making abilities. It needs to be easier to have different styles within one block of text; surely this is possible with css stylesheets in svg? I wish I had the coding ability to start implementing this. [[User:Legio noctis|Legio noctis]] 20:13, 12 January 2010 (UTC)

== others ==

[[http://www.google.pt/trends?q=inkscape%2Cxara&ctab=0&geo=all&date=all&sort=2 Google Trends to Inkscape and Xara]]

[[Category:Developer Discussion]]

CompilingMacOsX

2009-09-25T03:34:23Z

Ciradrak: /* Installing dependencies */ added purpose of cairo extension

= For the impatient =

1. Install [http://developer.apple.com/tools/xcode/ XCode tools] from your OS X installation DVD

2. Download and install [http://www.macports.org/ MacPorts]

3. In Terminal (Applications>Utilities>Terminal) type
<pre>sudo port sync
sudo port selfupdate
sudo port install cairo boehmgc gtkmm gtk-engines2 intltool libxslt lcms popt poppler boost \
gnome-vfs libgnomeprintui automake autoconf subversion</pre>

Note: subversion is pre-installed on Leopard, so you may be fine leaving subversion out of the port install command chain.

Grab a cup of coffee

4. In Terminal, get and build Inkscape
<pre>
svn co https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk inkscape
cd inkscape/packaging/macosx/
./osx-build.sh a c b i -s p</pre>

''Et voilà''. If you want to understand what you just did, read on.

= Requirements =
To compile Inkscape from source you need:
*Mac OS X > 10.3
*XCode Tools. They are on your installation DVD, in the optional installs, or can be download from [http://developer.apple.com/tools/xcode/ Apple Developer Connection]. You can customize the install to make it smaller (avoir documentation and example software for example). You need at least: gcc, XCode, X11SDK.
*Inkscape's source code. You can download an [http://www.inkscape.org/download.php official release source code], a [http://inkscape.modevia.com/svn-snap/?M=D development snapshot] or checkout a copy of the current state of the [http://www.inkscape.org/svn.php?lang=en SVN repository] using [http://subversion.tigris.org/ subversion]. Subversion comes pre-installed on Leopard. On previous system, subversion can be installed by package management systems (see point below) or with an OS X installer [http://homepage.mac.com/martinott/ package]
*A means of getting Inkscape's numerous dependencies: glibmm, gtkmm, lmcs, boehmgc... We recommend the use of [http://www.macports.org/ MacPorts] right now. ([http://www.finkproject.org/ Fink] was used in the past but it no longer meets Inkscape's needs currently.)

= Compiling Inkscape with X11, using MacPorts [Recommended method]=

== Installing dependencies ==
You can use MacPorts to list Inkscape dependencies:
<pre>port deps inkscape</pre>

Some are mandatory and you can install them with the command:
<pre>sudo port install boehmgc gtkmm gtk-engines2 intltool libxslt lcms popt boost gsl</pre>

Others provide additional functionality to Inkscape:
* <code>gnome-vfs</code> : access to remote servers, in particular import from Open Clipart Library
* <code>aspell</code> : check spelling of text elements [Note: I have never seen it working on OS X, though at least it should install fine]
* <code>libgnomeprintui</code>
* <code>loudmouth</code> : jabber library used by InkBoard
* <code>cairo</code> : ps and pdf export
* <code>poppler</code> : better pdf import
<pre>sudo port install gnome-vfs aspell libgnomeprintui loudmouth cairo poppler</pre>
NB: Cairo was already installed at previous step as a GTK dependency. You need to either deactivate the old version and install this one, or directly write it on the command line above.
If you're unsure about MacPorts commands, you can find a guide that is easy to skim here: [http://guide.macports.org/ MacPorts Guide]

In addition, Inkscape requires versions of the autotools more recent thant those that ship with OS X. Install them:
<pre>sudo port install autoconf automake</pre>

More recent (Sep 2008) pre-packaged nightly builds for Mac OS X also feature additional dependencies:
<pre>sudo port install librsvg libwpd libwpg libcroco</pre>

NB: At the time of editing (2008-12-01) there was a problem fetching "lzmautils" as the URL MacPorts tried to use as download source dies in a timeout.
As this package is needed as a dependency for one or more packages noted above you need to download the source tarball of lzmautils from somewhere else (for example, from [ftp://sunfreeware.mirrors.tds.net/pub/sunfreeware/SOURCES/lzma-4.32.7.tar.gz here]) and put that into the local MacPorts repository at "/opt/local/var/macports/distfiles/lzmautils". You should now be able to run the commands above.

Also make sure that you have "libxml2" and "libxslt" installed with MacPorts. This should have been installed previously, either directly or as a dependency.
You will need those later to compile the "lxml" Python module if you want to use Python effects. First check what's installed and if they are missing from your MacPorts repository install them by doing:

<pre>port installed
sudo port install libxml2 libxslt</pre>

== Pre-compiling the Python modules ==

If you cannot use the pre-built Python modules from [http://inkscape.modevia.com/macosx-snap/?C=M;O=D Modevia], say, because you're using an unsupported Python version or you just want to install from source you need to pre-compile both modules.

In case you are using a Python version installed through MacPorts do a search for both modules and install the ones suitable for the Python version activated within MacPorts.
<pre>port search lxml numpy</pre>

If you are using Leopard's default Python 2.5.1 installation or a more recent one (e.g. MacPython 2.6) you will need to compile both modules outside of MacPorts. Download both modules from [http://pypi.python.org PyPI] if they are available there for your Python version. At the time of editing (2008-12-01) both modules were only available through SVN for Python 2.6.

There are lots of tutorials for building and installing the "numpy" module. One good place to start looking is the [[GettingEffectsWorking#on_Mac_OS_X|Getting Effects Working]] entry referenced at the end of this guide.

Building the "lxml" module deviates a little from the standard way, so if you cannot install it try the following command:
<pre>cd /path/to/lxml/source
sudo python setup.py install \
--with-xslt-config=/opt/local/bin/xslt-config \
--with-xml2-config=/opt/local/bin/xml2-config</pre>

This tells it to use the libxml2 and libxslt packages we installed earlier with MacPorts instead of Mac OS X' default versions, which have been known to cause problems when trying to build "lxml".

If you are compiling the Python modules outside of MacPorts you will need to make a mental note for after running the .app-bundle building script (detailed [[CompilingMacOsX#Creating_an_.app_bundle|later]] in this guide) to copy the "lxml" and "numpy" dirs from the standard installation destination (by default "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages" for MacPython 2.6 and "/Library/Python/2.5/site-packages/" for Leopard's default Python 2.5.1 installation) to either
* the "extensions" folder inside the Inkscape.app bundle ("Inkscape.app/Contents/Resources/extensions") if all you care about is getting the Inkscape build to work with your Python version. This method is more foolproof but supports only one Python version.
* the "site-packages" folder inside the Inkspace.app bundle. The "site-packages" folder is the right place for putting your pre-compiled Python modules if you want to redistribute your build. Make a subfolder within "site-packages" with the name of your arch ("i386" for Intel, "PPC" for PowerPC or type <code>arch</code> into a Terminal window) and another subfolder within the arch folder with the name of your Python version (e.g. "2.5" or "2.6" etc.). This allows you to include support for multiple Python versions with your Inkscape build. Note, however, that if someone has multiple Python versions installed they may run into problems with the PATH order exported by the internal script ("Inkspace.app/Contents/Resources/bin/inkscape") responsible for preparing the Inkscape launch environment.

Armed with this knowledge you should be able to take care of the "...needs the fantastic libxml2 wrapper..." message when executing Python effects. Normally the <code>osx-app.sh</code> script (detailed [[CompilingMacOsX#Creating_an_.app_bundle|later]]) should take care of this for you, but if for whatever reason it didn't you know how to copy the modules manually.

For further info refer to the [[GettingEffectsWorking#on_Mac_OS_X|Getting Effects Working]] section of this wiki.

== Setting the build environment ==
MacPorts's hierarchy (/opt/local/) is not searched for libraries by default. Therefore, before the configuration starts, some environment variables need to be set. The environment variables are presented in bash syntax here.
<pre>export LIBPREFIX="/opt/local"
# automake seach path
export CPATH="$LIBPREFIX/include"
# configure search path
export CPPFLAGS="-I$LIBPREFIX/include"
export LDFLAGS="-L$LIBPREFIX/lib"
# compiler arguments
export CFLAGS="-O3 -Wall"
export CXXFLAGS="$CFLAGS"
</pre>

You can also use <code>[http://en.wikipedia.org/wiki/Ccache ccache]</code> (<code>sudo port install ccache</code>) to speed up the compilation a bit. To do so, add compiler variables:
<pre>export CC="ccache gcc"
export CXX="ccache g++"</pre>

== Configuring ==
If you compile Inkscape for the first time from an svn checkout you need to generate the configure script. Navigate to Inkscape's source directory and run:
<pre>./autogen.sh</pre>

Then run configure with the options <code>--disable-static --enable-shared</code> and <code>--prefix</code> which sets the directory where the build products are placed. It must be somewhere you have write access to.
<pre>./configure --disable-static --enable-shared --prefix=/path/to/build/products/</pre>

If you want to package Inkscape into a double-clickable <code>.app</code> bundle in order to access it like a regular OS X application (you probably want to), you need to add the option <code>--enable-osxapp</code>:
<pre>./configure {...} --enable-osxapp</pre>

If you have loudmouth installed and you want to enable whiteboard functionality in Inkscape, add <code>--enable-inkboard</code>.

Other configuration options can be set, check the list of options by issuing:
<pre>./configure --help</pre>

Here's an example which covers most options that can be set:
<pre>./configure --disable-static --enable-shared --prefix=/path/to/build/products/ --with-xft \
--with-gnome-vfs --with-python=/path/to/python/modules --enable-osxapp --enable-lcms \
--enable-poppler-cairo --enable-inkboard</pre>

== Building and Installing ==
Just run:
<pre>make
make install</pre>

== Creating an .app bundle ==
Assuming that you have used the <code>--enable-osxapp</code> option during <code>configure</code>, navigate to Mac OS X packaging directory in Inkscape source code and use the automated script:
<pre>cd packaging/macosx
./osx-app.sh -s -b /path/to/install/prefix/bin/inkscape -p ../../Info.plist</pre>
The script copies Inkscape binary and all its dependencies into the app bundle. The <code>-s</code> options strips libraries from debugging information (the bundle is therefore smaller). Omit this option if you want to keep debugging info.

== Creating a disk image to distribute Inkscape ==
Inkscape.app created at the previous step is completely independent from the original location of MacPorts libraries and can therefore be distributed. It will only work on your platform though (PPC or Intel) and incompatibilities are known between X11 versions on different major versions of OS X (Panther, Tiger and Leopard). The general rule is that versions are not backward compatible.

The most widespread way of distributing applications on Mac OS X is via .dmg images. You can created a dmg image of Inkscape, with a nice background and all, using the script:
<pre>./osx-dmg.sh -p Inkscape.app</pre>
in the packaging directory for Mac OS X (where your app bundle should be, otherwise modify the path to Inkscape.app).

== Automated build script ==
All essential steps are automated by a build script: <code>osx-build.sh</code>. It has built-in help so to know how to use it just type:
<pre>./osx-build.sh help</pre>

NB: Excluded steps involve Pre-compiliation of the Python modules and installing the additional nightly build features.

= Compiling a Universal Binary of Inkscape with X11, using MacPorts=

These instructions should work on both 10.4 and 10.5 machines with the latest Xcode version installed.

== Build Universal dependencies ==

The easiest way to do this is to create a new Macports installation. It is recommended that you install macports from source into a long prefix (of 50 character) such as "/opt/local-macports-with-a-really-long-directory-name/" -- this will allow enough space to later perform path rewriting on all the bundled libraries.

Once you have installed Macports, edit the $PREFIX/etc/macports/variants.conf file to have the following line:
<pre>+universal</pre>
This will cause Macports to install the Universal variant of each package you later ask it to install.

If you already have non-universal versions of some ports installed, for each of these you may need to deactivate the port and rebuild it, e.g.
<pre>sudo port -f uninstall cairo
sudo port clean cairo
sudo port -v install cairo +universal</pre>

== Build Universal Inkscape ==

First, Set your SDK, 10.5 for Leopard, 10.4u for TIger:

<CODE>export SDK=/Developer/SDKs/MacOSX10.5.sdk</code>     (For Leopard)<br />
<CODE>export SDK=/Developer/SDKs/MacOSX10.4u.sdk</code>     (For Tiger)<br />

Then, set up your environment to point to the Macports libraries:
<pre>export MACPORTS="/opt/local"
export PATH=$MACPORTS/bin:$MACPORTS/sbin:/usr/X11R6/bin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin
# automake seach path
export CPATH="$MACPORTS/include"
# configure search path
export CPPFLAGS="-I$MACPORTS/include"
export LDFLAGS="-L$MACPORTS/lib"
# compiler arguments
export CFLAGS="-O3 -Wall -isysroot $SDK -arch ppc -arch i386"
export CXXFLAGS="$CFLAGS"</pre>

The final step is to configure and compile Inkscape. Inkscape must be configured with the following options:

<code>--enable-osxapp</code>     Sets the correct path for Inkscape to be used from an .app bundle<br />
<code>--disable-dependency-tracking</code>     Dependency tracking can't be used when compiling universal binaries.

Inkscape can then be built (with make), installed, and packaged into a Universal .app bundle using the standard .app bundle building instruction above.

= Compiling Inkscape with native GTK using MacPorts [experimental] =
This process is very similar to compiling an X11 version of Inkscape except for the building of dependencies: need to build native versions of Inkscape dependencies. At the moment (2007-12-17) this process does not produce a usable version of Inkscape but the more people try to use it, the quicker the bugs will be ironed out!

== Native version of Inkscape dependencies ==
Thanks to the power of port "variants" and port "deactivation" you can install native versions of gtk, cairo, pango and such, alongside the regular X11 ones. To know which ports have a <code>quartz</code> or <code>no_x11</code> variant, use the command:
<pre>port list variant:quartz variant:no_x11</pre>
This will give you an idea of what need to be replaced.

Assuming your MacPorts tree has been already used to build regular versions of Inkscape, you first need to deactivate (suppress from the tree without really uninstalling) the X11 versions of gtk, cairo, cairomm and pango:
<pre>sudo port deactivate gtk2 cairo cairomm pango</pre>

Then install native variants:
<pre>sudo port install cairo +quartz+no_x11 cairomm pango +no_x11 poppler +quartz gtk2 +quartz</pre>

== Installing a second Macports tree (recommended approach) ==
Rather than deactivating and reactivating ports, you can also keep two MacPorts trees side by side, provided you install the second one from source. Let say I want to install a new tree for native versions in /opt/local/native, I would do
<pre>export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
cd ~/MacPorts-1.x.x/
./configure --prefix=/opt/local-native --with-tclpackage=/Library/Tcl/macports-native
make
sudo make install</pre>

You can set this second tree up to always build packages with specific variants. For example, you can edit the /opt/local-native/etc/macports/variants.conf file to have the following line:
<pre>+universal +no_x11 +quartz</pre>
You can remove the +universal if you only want to build inkscape for your host architecture.
You may also need to set alternate applications_dir and frameworks_dir variables in the /opt/local-native/etc/macports/macports.conf file so that applications and frameworks install by this macports (for example by python) don't clash with your standard macports tree.

Then you need to have only one version of the port command in the path at any time so you need to setup your .bashrc (or .bash_profile or .profile) accordingly. I use shell aliases to quickly and temporarily switch to the universal version:
<pre>alias portpathregular="export PATH=/opt/local/bin:/opt/local/sbin:/Developer/Tools:/usr/local/bin: \
/usr/X11R6/bin:/bin:/sbin:/usr/bin:/usr/sbin"
alias portpathnative="export PATH=/opt/local-native/bin:/opt/local-native/sbin:/Developer/Tools:/usr/local/bin: \
/usr/X11R6/bin:/bin:/sbin:/usr/bin:/usr/sbin"</pre>
NB: the \ are just to mark line continuation here, suppress them and put everything in one line.

== Install the rest ==
Eventually, follow the regular install procedure for the rest:
<pre>sudo port install libxslt boost boehmgc gtkmm lcms intltool popt</pre>
If your MacPorts tree was already ready to compile Inkscape, you should not need to reinstall anything, with the possible exception of gtkmm, which may need to be rebuilt against the native version of gtk rather than against the X11 one (please someone confirm this).

Get inkscape source code and go in the mac OS X specific packaging directory
<pre>cd packaging/macosx</pre>
There edit <code>osx-build.sh</code> to remove the configure option <code>--enable-osxapp</code> because it puts inkscape in a .app bundle where it is started together with X11, which would defeat the purpose of this native compilation. You can also specify an alternative install prefix if you want. Then
<pre>./osx-build.sh u a c b i</pre>
and a native version of Inkscape is installed in the prefix you specified or in the <code>Build/bin</code> directory of Inkscape's source code. You can test it by
<pre> cd ../../Build/bin/
./inkscape</pre>

NB: if you compiled a GTK theme engine against your old GTK install (i.e. the one with X11) and try to use it with the new install, it will complain, so edit <code>~/.gtkrc-2.0</code> to remove the offending theme or recompile it with the new native GTK.

= Enabling python effects =
moved to [[GettingEffectsWorking]]. They should work out of the box in the new versions anyway.

= Links =

== User Examples ==
* Adam Strzeleki has outlined some improvements to this process on the Inkscape [http://www.nabble.com/Inkscape-native-Mac-OS-X-build---look-improvements-td14733036.html email list]. See his screenshot from January 10, 2008 [http://www.nabble.com/attachment/14733036/1/Inkscape%20OSX%20PL.gif here].
* JiHO has a video of his builds [http://jo.irisson.free.fr/?p=34 here] and [http://jo.irisson.free.fr/?p=62 here].

== Apple Documentation ==
* [http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/BPRuntimeConfig.html Introduction to Runtime Configuration] Covers the Info.plist files, Preferences, Environment variables and has a list of the most important Properties that the Property List should contain.

== Packaging ==

* [http://www.sveinbjorn.org/platypus Sveinbjorn Thordarson's Website] The author of Platypus, the Script Exec wrapper that launches the Inkscape binary.
* [http://freespace.ausgamers.com/2005/02/creating-os-x-application-bundles-step.html Creating OS X application bundles step by step] Covers the bundle concepts, copying libraries into the bundle, editing libraries with the install_name_tool, the Info.plist file and adding an icon.
* [http://java.sun.com/developer/technicalArticles/JavaLP/JavaToMac3/ Bringing your Java Application to Mac OS X] I would regard this a little dated, and the detail is (unsurprisingly) Java-related, but it is a gentle introduction to the role of the .app bundle and give a most clear account of how to create one.
* The [http://gimp-app.sourceforge.net/gimp.app.howto.txt Gimp .app Howto] This is a very bare document, and would be of little help to you if you were new to making packages. Note that it seems to refer to a more mature Clipboard technique and Online help than we currently have; and we ought to move to parity in these areas.

[[Category:Developer Documentation]]