Inkscape Wiki - User contributions [en]

Dialog

2013-08-25T11:43:53Z

Romain2Boss: /* Listing */

By extension, a '''dialog''' in Inkscape vocabulary is any type of window, i.e. a set of widgets with an OS decoration, a title...

== Location ==

All dialogs are in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/dialog src/ui/dialog] (except for old dialogs).

== Listing ==

* [[About Dialog]]
* [[Align and Distribute Dialog]]
* [[Class Inkscape::UI::Dialog::Behavior::Behavior]]
* [[Class Inkscape::UI::Dialog::Behavior::DockBehavior]]
* [[Class Inkscape::UI::Dialog::Behavior::FloatingBehavior]]
* [[Class Inkscape::UI::Dialog::CaligraphicProfileRename]]
* [[Close Dialog]]
* [[Class Inkscape::UI::Dialog::ColorItem]]
* [[Debug Dialog]]
* [[Class Inkscape::UI::Dialog::DesktopTracker]]
* [[Class Inkscape::UI::Dialog::Dialog]]
* [[Class Inkscape::UI::Dialog::DialogManager]]
* [[Document Metadatas Dialog]]
** [[Andrews Big Dialog Re-Design/Document Metadata]]
* [[Document Properties Dialog]]
* [[Class Inkscape::UI::Dialog::ExtensionEditor]]
* [[Class Inkscape::UI::Dialog::ExtensionPanel]]
* [[Export Bitmap Dialog]]
** [[Export Bitmap Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/Export Bitmap]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseGtk]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseWin32]]
* [[Class Inkscape::UI::Dialog::FileDialogOCALBase]]
* [[Class Inkscape::UI::Dialog::FileImportFromOCALDialog]]
* [[Class Inkscape::UI::Dialog::FileListViewText]]
* [[Class Inkscape::UI::Dialog::FileOpenDialog]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileSaveDialog]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileExportDialog]]
* [[Class Inkscape::UI::Dialog::FileExportDialogImpl]]
* [[Stroke Dialog]]
** [[Fill and Stroke Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::FilterEffectsDialog]]
* [[Find Dialog]]
* [[Class Inkscape::UI::Dialog::GlyphsPanel]]
* [[Class Inkscape::UI::Dialog::GuidelinePropertiesDialog]]
* [[Class Inkscape::UI::Dialog::IconPreviewPanel]]
* [[Image Properties Dialog]]
** [[Image properties dialog enhancements]]
* [[Inkscape Preferences Dialog]]
* [[Class Inkscape::UI::Dialog::InputDialog]]
* [[Layer Dialog]]
* [[Layer Properties Dialog]]
* [[Class Inkscape::UI::Dialog::LayersPanel]]
* [[Class Inkscape::UI::Dialog::LivePathEffectEditor]]
* [[New Document Dialog]]
* [[Memory Dialog]]
* [[Messages Dialog]]
* [[OCAL Dialog]]
** [[OCAL Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/OCAL]]
* [[Class Inkscape::UI::Dialog::PanelDialogBase]]
* [[Print Dialog]]
* [[Class Inkscape::UI::Dialog::PrintColorsPreviewDialog]]
* [[Script Dialog]]
* [[Class Inkscape::UI::Dialog::SvgFontsDialog]]
* [[Class Inkscape::UI::Dialog::SVGPreview]]
* [[Class Inkscape::UI::Dialog::SwatchesPanel]]
* [[SymbolsDialog|Symbols Dialog]]
* [[Tablet Dialog]]
* [[Text Dialog]]
* [[Tile Dialog]]
* [[Trace Bitmap Dialog]]:
** [[Trace Bitmap Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::Transformation]]
* [[Undo History Dialog]]

Dialogs that have not yet been rewritted can be found in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/dialogs src/dialogs].

== Re-designs ==

* [[Andrews Big Dialog Re-Design]]
* [[Andrews Big Dialog Re-Design/Embed or Link]]
* [[FindReplaceDialog]]
* [[DialogsReorganization]]

== Create a new dialog ==

Creating a new dialog requires the following steps:

# Create a new dialog in ''src/ui/dialogs'' (you can find inspiration from the existing dialogs).
# Register your dialog in ''src/dialogs/dialog-manager.cpp''.
# In ''src/verbs.cpp'', create a new [[verb]] (new DialogVerb) and associate it (DialogVerb::perform) with the dialog's registered name to perform the appropriate action. Also include your dialog's header in the ''verbs.cpp'' file.
# If needed, map the new verb to the preferences (SPDesktop::show_dialogs() in ''src/desktop.cpp'').
# Call the dialog from the appropriate location with ''dt->_dlg_mgr->showDialog("mydialog")'', ''dt'' being the current ''SPDesktop''.

[[Category:Dialogs]]
[[Category:Developer Documentation]]

Keyboard profiles

2013-08-25T11:28:33Z

Romain2Boss:

Several people suggested that making keyboard shortcuts user-configurable and providing "profiles" imitating other vector editors. There are currently four categories of shortcuts, and not all of them are equally easy to make user-configurable:

* [[Verb|Global verbs]] (in shortcuts.cpp): these work everywhere (both in document and in dialogs) except text-editing dialog widgets. They switch tools, zoom, etc.; they should be easy to read from a config file.

* Global context shortcuts (in event-context.cpp): these work in all tools but only within the document window. These are actions that make no sense without a document window, e.g. panning the canvas by ctrl-arrows. These are more tricky to make configurable.

* Per-tool shortcuts (in select-context.cpp, node-context.cpp, etc): these are actions specific to the tool. They are difficult to make configurable, and moreover, many of the actions they trigger would have no exact match in other vector apps.

* Widget shortcuts in dialogs, such as Tab for moving between widgets. I don't know how to change these, and anyway they are mostly standard enough so we don't need to bother with them.

So perhaps as a first step, we can make global verbs configurable and see if this is sufficient to imitate other vector apps well enough.

== What is to be done ==

If you like this idea, you could already start working towards this. Please pick your favorite non-Inkscape vector app and make a list of its shortcuts and corresponding functions. Please also categorize each function into one of the following groups:

1. There is a corresponding function (with the same or different shortcut) in shortcuts.cpp (i.e. this is a global verb in Inkscape).

2. There is no such function in shortcuts.cpp but such a function is listed on the [[KeyboardShortcuts]] wiki page (which tracks all shortcuts currently implemented in Inkscape).

3. There's no such function in Inkscape, but it would be relatively straightforward to implement it.

4. There's no such function in Inkscape, and it's not clear how to implement it (i.e. we don't have such a tool, or palette, etc.).

Please use Wiki for creating your lists. You can link your list pages from this page and from under "Interface discussions" on the Wiki front page.

HowToEditIcons

2013-08-25T11:27:56Z

Romain2Boss:

BULIA SAYS:

My opinion on the desirable icon style is here:

[[IconsStyle]]

Other than that, it's difficult to give advice. All I can say is that e.g. the group/ungroup and z-order icons are ugly and noisy, while the flip icons are OK. Icons IMHO must be simple and laconic, not "realistic" or "3D". Just go on and try to draw something and we'll comment :)

=== Procedure ===

As for the procedure, draw new icons in share/icons/icons.svg, group each icon and assign an id to the group via the "item properties" dialog (you can also use the XML editor), and then you specify that id for the corresponding [[verb]] in verbs.cpp (the last component of each line of props[]).

I'd like everyone who commits icons.svg to also make sure they have the following in ~/.inkscape/preferences.xml, before they save the file:

<group
id="svgoutput"
usenamedcolors="0"
numericprecision="7"
minimumexponent="-8"
inlineattrs="1"
indent="0" />

This makes quite a difference in file size, and for such time-critical file as this, every millisecond counts. Thanks!

[[Category:Developer Documentation]]

EventContextGrab

2013-08-25T11:27:29Z

Romain2Boss:

As first discussed in [[InkscapeTamed]], keyboard events are sent to the event context handlers (both global in event-context.c and tool-specific e.g. select-context.c) ONLY when the mouse is over the canvas.

Simple experiment: move a shape by arrows. This works while the mouse cursor is over the document window but stops as soon as you move mouse away from it, even if the document window still has focus. [[Verb|Global verbs]] like + and - and ctrl-q always work. We cannot however make tool-specific shortcuts global verbs.

* Mental writes:

Grabbing focus between widgets is accomplished via
gtk_widget_grab_focus(). The widget will need to have the GTK_CAN_FOCUS
flag set, however. I've taken care of the latter half in desktop.c now (setting the
CAN_FOCUS widget flag).

I guess what remains is just determining when it would be appropriate to
call gtk_widget_grab_focus() on the canvas widget.

* bb writes:

I cannot make it work. I added

gtk_widget_grab_focus (&(dtw->canvas->widget));

into sp_desktop_widget_new in desktop.c. For debugging, I also added

gtk_signal_connect (GTK_OBJECT (&(dtw->canvas->widget)), "event", GTK_SIGNAL_FUNC (sp_canvas_event_handler), &(dtw->canvas->widget));

and put some debug output into sp_canvas_event_handler. With or without the
grab, it looks like the canvas widget gets keypresses, but does not pass
them on to the event context. That is, it does pass it to the event context
but only when the mouse is within the canvas.

Maybe we need to grab focus on the event context, not on the canvas? But how
to do that? I think the event context is not a GTK widget.

* Mental responds:

Well, grab_focus() isn't like a window "grabbing" focus;
gtk_widget_grab_focus() is the normal mechanism for widgets handing
focus off to one another.

_new() likely isn't the time to call it, because its effect is not
persistent.

So it would need to be called e.g. when the canvas widget is clicked or
moused over or something like that.

Thinking about it, I _believe_ (I will have to double-check) that
events are actually passed to the event context by the enclosing
[ventBox (GtkDesktopWidget is a descendant of GtkEventBox).

* and then adds:

Ick.

To be honest I still don't totally understand how events are handed off
to event contexts in Sodipodi/Inkscape. :/

> Maybe we need to grab focus on the event context, not on the canvas? But how
> to do that? I think the event context is not a GTK widget.

Well, ultimately _some_ widget must receive the events and passing them
on to the event context. We need to figure out which widget that
is/should be.

-----

UPDATE: OK, I think I fixed that. Now the canvas always gets all keys, including arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the document window has focus. This closes a sore "known problem" from 0.36 release notes.

I'm not sure if my fix is "correct" but it seems to work. Previously, event contexts received events only from the "acetate" item on the canvas (this is an invisible item covering the entire canvas), and this item obviously can only have focus when mouse is over it. We have tried putting event grab on the canvas widget, but this apparently did not affect the acetate which, not being a GTK widget, cannot have a grab. My solution is simply to call sp_desktop_root_handler() from within the sp_desktop_widget_event() handler (which receives all desktop widget events regardless of mouse position) but only for GDK_KEY_PRESS events and only if the desktop's canvas has no current item (because in that case, an item handler must be called instead of root handler, and I don't need to do that anyway because this can only happen when the mouse is over the canvas).

[[Category:Wiki Attic]]

Developer manual

2013-08-25T11:26:21Z

Romain2Boss:

= 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 <code>experimental</code> 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 <s>[http://www.cs.helsinki.fi/u/vkarvone/2004s/cplusplus/errors.html schoolboy errors] (Broken Link)</s>. None of these should appear in [http://en.wikipedia.org/wiki/Free/Libre/Open-Source_Software FLOSS] code.

== Please use const ==

Please be very aggressive in adding ''const'' to any code you write. It will help us understand code better and will prevent bugs from creeping in. It is very easy to remove ''const'' later on, but very hard to add it.

''const'' can go on either side of a type. However once you get into references and pointers and such with C++, you generally read those from right-to-left. So it makes the code a little more legible if the ''const'' comes between the variable type and name.

int const foo;
// RTL reading gives "foo is a constant int".

And then:

int const & foo;
// RTL reading gives "foo is a reference o a constant int"

int const * foo;
// RTL reading gives "foo is a pointer to a constant int"

whereas:

int * const foo;
// RTL reading gives "foo is a constant pointer to an int"

Read also:
* [http://www.cprogramming.com/tutorial/const_correctness.html Const Correctness]
* [http://yosefk.com/c++fqa/const.html Const Correctness]

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

<code>"Select object"</code>
becomes
<code>_("Select object")</code>

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.
<code>"Ambiguous string"</code>
can then become
<code>C_("Context", "Ambiguous string")</code>

For more complex things, please check the gettext/localization documentation.
See also http://library.gnome.org/devel/glib/unstable/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. 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, in order to ensure 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’s 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 do feathering and blur, and a 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. These are all 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:

<ol>
<li>Find the appropriate tags and attributes in the SVG spec</li>
<li>Implement support for rendering files with these tags</li>
<li>Implement support for UI controls to edit the tags</li>
</ol>

Step 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.

Step 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.

Step 3 is the most important stage. 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
(<code>sp_verb_t</code>) is maintained in <code>shortcuts.cpp</code>; these are registered using
<code>sp_shortcut_set()</code>.

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

<code>SPActions</code> derive from <code>NRActiveObject</code>, which putatively provides a
“lightweight” method of doing callbacks (vs <code>GObject</code> signals). I
don’t completely understand how it works.

<code>SPActions</code> also contain the label, image, etc, used for buttons and
menuitems.

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

== Garbage collection ==

As you know, many automatic garbage collectors (like <code>libgc</code>) 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 <code>malloc()</code> or some custom allocator like <code>libgc</code>’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.

For example, let’s say 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, <code>libgc</code>’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 <code>top(1)</code>...

(The worst thing is, 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 2004) 

* 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 <code>NRArenaShape</code> currently holds onto an <code>SPStyle</code> 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 <code>SPObject::hrefcount</code>).

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).

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

== Inkscape Experimental SVN ==

The <code>experimental</code> 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 <code>experimental/</code> 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 that’s okay.

When an experiment has matured to the point of being actually useful, please move it out of
the experimental module to someplace more appropriate. 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 <code>share</code> 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 <code>inkscape/share/</code> (except <code>AUTHORS</code> and <code>NEWS</code> 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 <code>/usr/share/flags-svg/</code>, 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 <code>src/</code>, 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 <code>.svgz</code> files: Is the server sending the right <code>Content-Encoding:</code> 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]]

Dialog

2013-08-25T11:24:33Z

Romain2Boss: Created page with "By extension, a '''dialog''' in Inkscape vocabulary is any type of window, i.e. a set of widgets with an OS decoration, a title... == Location == All dialogs are in [http://..."

By extension, a '''dialog''' in Inkscape vocabulary is any type of window, i.e. a set of widgets with an OS decoration, a title...

== Location ==

All dialogs are in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/dialog src/ui/dialog] (except for old dialogs).

== Listing ==

* [[About Dialog]]: The ''About Inkscape'' dialog
* [[Align and Distribute Dialog]]: The ''Align and distribute'' dialog
* [[Class Inkscape::UI::Dialog::Behavior::Behavior]]
* [[Class Inkscape::UI::Dialog::Behavior::DockBehavior]]
* [[Class Inkscape::UI::Dialog::Behavior::FloatingBehavior]]
* [[Class Inkscape::UI::Dialog::CaligraphicProfileRename]]
* [[Close Dialog]]
* [[Class Inkscape::UI::Dialog::ColorItem]]
* [[Class Inkscape::UI::Dialog::DebugDialog]]
* [[Class Inkscape::UI::Dialog::DesktopTracker]]
* [[Class Inkscape::UI::Dialog::Dialog]]
* [[Class Inkscape::UI::Dialog::DialogManager]]
* [[Class Inkscape::UI::Dialog::DocumentMetadata]]: The ''Document metadatas'' dialog
** [[Andrews Big Dialog Re-Design/Document Metadata]]
* [[Class Inkscape::UI::Dialog::DocumentProperties]]: The ''Document properties'' dialog
* [[Class Inkscape::UI::Dialog::ExtensionEditor]]
* [[Class Inkscape::UI::Dialog::ExtensionPanel]]
* [[Export Bitmap Dialog]]
** [[Export Bitmap Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/Export Bitmap]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseGtk]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseWin32]]
* [[Class Inkscape::UI::Dialog::FileDialogOCALBase]]
* [[Class Inkscape::UI::Dialog::FileImportFromOCALDialog]]
* [[Class Inkscape::UI::Dialog::FileListViewText]]
* [[Class Inkscape::UI::Dialog::FileOpenDialog]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileSaveDialog]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileExportDialog]]
* [[Class Inkscape::UI::Dialog::FileExportDialogImpl]]
* [[Stroke Dialog]]
** [[Fill and Stroke Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::FilterEffectsDialog]]
* [[Find Dialog]]
* [[Class Inkscape::UI::Dialog::GlyphsPanel]]
* [[Class Inkscape::UI::Dialog::GuidelinePropertiesDialog]]
* [[Class Inkscape::UI::Dialog::IconPreviewPanel]]
* [[Image Properties Dialog]]
** [[Image properties dialog enhancements]]
* [[Class Inkscape::UI::Dialog::InkscapePreferences]]: The ''Inkscape preferences'' dialog
* [[Class Inkscape::UI::Dialog::InputDialog]]
* [[Layer Dialog]]
* [[Class Inkscape::UI::Dialog::LayerPropertiesDialog]]: The ''Layer properties'' dialog
* [[Class Inkscape::UI::Dialog::LayersPanel]]
* [[Class Inkscape::UI::Dialog::LivePathEffectEditor]]
* [[New Document Dialog]]
* [[Memory Dialog]]
* [[Messages Dialog]]
* [[OCAL Dialog]]
** [[OCAL Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/OCAL]]
* [[Class Inkscape::UI::Dialog::PanelDialogBase]]
* [[Print Dialog]]: The ''Print...'' dialog
* [[Class Inkscape::UI::Dialog::PrintColorsPreviewDialog]]
* [[Script Dialog]]
* [[Class Inkscape::UI::Dialog::SvgFontsDialog]]
* [[Class Inkscape::UI::Dialog::SVGPreview]]
* [[Class Inkscape::UI::Dialog::SwatchesPanel]]
* [[SymbolsDialog|Symbols Dialog]]
* [[Tablet Dialog]]
* [[Text Dialog]]
* [[Tile Dialog]]
* [[Class Inkscape::UI::Dialog::TraceDialog]]
** [[Trace Bitmap Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::Transformation]]
* [[Class Inkscape::UI::Dialog::UndoHistory]]: The ''Undo history'' dialog

Dialogs that have not yet been rewritted can be found in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/dialogs src/dialogs].

== Re-designs ==

* [[Andrews Big Dialog Re-Design]]
* [[Andrews Big Dialog Re-Design/Embed or Link]]
* [[FindReplaceDialog]]
* [[DialogsReorganization]]

== Create a new dialog ==

Creating a new dialog requires the following steps:

# Create a new dialog in ''src/ui/dialogs'' (you can find inspiration from the existing dialogs).
# Register your dialog in ''src/dialogs/dialog-manager.cpp''.
# In ''src/verbs.cpp'', create a new [[verb]] (new DialogVerb) and associate it (DialogVerb::perform) with the dialog's registered name to perform the appropriate action. Also include your dialog's header in the ''verbs.cpp'' file.
# If needed, map the new verb to the preferences (SPDesktop::show_dialogs() in ''src/desktop.cpp'').
# Call the dialog from the appropriate location with ''dt->_dlg_mgr->showDialog("mydialog")'', ''dt'' being the current ''SPDesktop''.

[[Category:Dialogs]]
[[Category:Developer Documentation]]

User Interface Modules

2013-08-25T11:21:02Z

Romain2Boss: /* Dialogs */

Discussion and documentation about specific Inkscape dialogs, widgets, tools and more inside the [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/ src/ui] directory.

== Dialogs ==

See [[Dialog]].

== Widgets ==

Widgets are implemented in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/widget src/ui/widget].

* [[Class Inkscape::UI::Widget::ColorPreview]]: A simple color preview widget, mainly used within a picker button
* [[Class Inkscape::UI::Widget::ProgressPannel]]
* [[Class Inkscape::UI::Widget::SpinButton]]: Widget that allows entry of simple math expressions (also units, when linked with UnitMenu), and allows entry of both '.' and ',' for the decimal, even when in numeric mode
* [[Class Inkscape::UI::Widget::SpinSlider]]: Groups an Gtk::HScale and a Inkscape::UI::Widget::SpinButton together using the same Adjustment
* ...

Also a proposal for a [[Color Entry Widget|Color Entry]].

== src/ui/tools ==
* ...

== Toolbars ==

A '''toolbar''' is a set of graphical widgets put around the canvas to provide actions on objects, canvas or documents.

See [[Toolbar]] page for more informations.

== Menu ==

See [[Menu]].

[[Category:Developer Documentation]]

SpecElectronicsCAD

2013-05-25T11:03:49Z

Romain2Boss:

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing
** This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)
** To ease this, schematic and PCB layout could be placed on different layers of a single SVG file

===Not so hard===
* Gnd/other plane fills
** I think there already is a live path effect for that
* Clearance calculation/DRC
** This naturally is part of the netlist generation
* PCB layers
** Can be implemented by SVG classes. When SVG 2.0 comes around, these can be assigned z-order attributes.
** Most other parts of Inkscape do not need to be aware of these classes, they only need special treatment when exporting to PCB formats.
** PCB layer classes are assigned when creating a component. Some kind of GUI would be nice for this.
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Does not seem too complicated. Since the heavy lifting is done by 2geom this could be implemented in python.
** Propagate net names (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
Inkscape's symbol functionality already supports most of this.

===Component features===
# Like groups, components group objects together
# Components have some metadata/parameters associated with them
# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
# Components can have ''terminals'' or ''pins'' (for trace routing and netlist generation). This nicely maps to the ''point'' elements described in the SVG Connector draft

===Required code===
* Python interface for parametric symbol generation

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

[[Category:Proposals]]
[[Category:Specification]]

DirectoryReorgProposal

2013-05-25T11:03:25Z

Romain2Boss:

== Directory Reorganization Proposal ==

[Iniitally proposed Feb 11, 2004 by B. Harrington on inkscape-devel@]

=== Distribution / Packaging Files ===

Presently, we have a number of files in the codebase related to
generation of distribution packages. Some of these files are in the
root inkscape/ directory, others are in subdirs like inkscape/debian/.

To head off potential clutter as Inkscape becomes supported on a wider
variety of systems, we should collect as many of these packaging files
as feasible into a subdir called inkscape/packaging/.

Inside that directory would be distro-specific subdirs, plus a common
directory for shared scripts and collateral:

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

=== Config Files ===

Currently we do not have global config files, but instead put the config
file in the user's home dir in ~/.inkscape/. These are generated at
run-time by Inkscape itself, so the defaults are hard-coded into the
application, and can't be customized by the sysadmin except by editing
the appropriate header file and recompiling/repackaging the app.

The correct approach for Linux apps is to have both user and global
configs, and to use the global as the default if the user does not yet
have a config file. This way, site customizations are known (such as
the fact that its shared files are in /usr/share, vs. /usr/local/share,
vs. /opt/inkscape/share, etc.)

The proposal is for Inkscape to establish its config file location in
/etc/inkscape/, and to place a global preferences.xml file there, as
well as any other config files we need later, like extensions.xml, etc.

Ideally, the global config file would be loaded first, and then the user
config file "override" any portion of the global options. This way the
user config file only needs to contain customizations, so that if we
choose to change the defaults in a future install, the user's config
files do not necessarily become invalid.

Inside the CVS codebase, the default etc. files would be stored in
inkscape/etc/, instead of being produced by the application at runtime.
During installation, installation-specific parameters (such as alternate
paths for various files) will be substituted in appropriately.

[Note: There is a proposal to use GConf in favor of flat config files,
which would make this section of the proposal unnecessary. -- Bryce]

=== "Share" Collateral ===

Inkscape currently generates a /usr/local/share/inkscape/ directory
during install, and copies the contents of the codebase's icons/
directory to that location.

We need more pieces of collateral installed, and need to do so in a more
organized manner. The recommendation is to establish a set of subdirs
in /usr/local/share/inkscape/, as follows:

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

This uses a flat hierarchy for the sake of simplicity.

In the CVS codebase, all of these would be placed in inkscape/share/ (except AUTHORS and NEWS which will be copied to share).
This way, the installation script could be set up to recursively copy
everything in that directory to the target share directory, and we won't
need to specify each of the subdirs in that script, which will make
maintenance less hassle.

For clipart, I think we definitely want to consider being able to tie in
with "external" clipart collections. One way would be to simply put
symlinks in the clipart dir to those collections. This way, if the
flags package were to install into /usr/share/flags-svg/, we'd just
symlink there.

Possibly similarly for extensions.

I think an argument could be made that the tutorials ought to be placed
somewhere under the /usr/doc/ or /usr/local/doc/ path, so I'm not 100%
certain of having the tutorials located here.

[[Category:Proposals]]

Developer manual

2013-04-14T10:34:06Z

Romain2Boss: Add "Please use const" following a developper discussion

= 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 <code>experimental</code> 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 <s>[http://www.cs.helsinki.fi/u/vkarvone/2004s/cplusplus/errors.html schoolboy errors] (Broken Link)</s>. None of these should appear in [http://en.wikipedia.org/wiki/Free/Libre/Open-Source_Software FLOSS] code.

== Please use const ==

Please be very aggressive in adding ''const'' to any code you write. It will help us understand code better and will prevent bugs from creeping in. It is very easy to remove ''const'' later on, but very hard to add it.

''const'' can go on either side of a type. However once you get into references and pointers and such with C++, you generally read those from right-to-left. So it makes the code a little more legible if the ''const'' comes between the variable type and name.

int const foo;
// RTL reading gives "foo is a constant int".

And then:

int const & foo;
// RTL reading gives "foo is a reference o a constant int"

int const * foo;
// RTL reading gives "foo is a pointer to a constant int"

whereas:

int * const foo;
// RTL reading gives "foo is a constant pointer to an int"

Read also:
* [http://www.cprogramming.com/tutorial/const_correctness.html Const Correctness]
* [http://yosefk.com/c++fqa/const.html Const Correctness]

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

<code>"Select object"</code>
becomes
<code>_("Select object")</code>

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.
<code>"Ambiguous string"</code>
can then become
<code>C_("Context", "Ambiguous string")</code>

For more complex things, please check the gettext/localization documentation.
See also http://library.gnome.org/devel/glib/unstable/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. 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, in order to ensure 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’s 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 do feathering and blur, and a 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. These are all 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:

<ol>
<li>Find the appropriate tags and attributes in the SVG spec</li>
<li>Implement support for rendering files with these tags</li>
<li>Implement support for UI controls to edit the tags</li>
</ol>

Step 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.

Step 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.

Step 3 is the most important stage. 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
(<code>sp_verb_t</code>) is maintained in <code>shortcuts.cpp</code>; these are registered using
<code>sp_shortcut_set()</code>.

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

<code>SPActions</code> derive from <code>NRActiveObject</code>, which putatively provides a
“lightweight” method of doing callbacks (vs <code>GObject</code> signals). I
don’t completely understand how it works.

<code>SPActions</code> also contain the label, image, etc, used for buttons and
menuitems.

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

== Garbage collection ==

As you know, many automatic garbage collectors (like <code>libgc</code>) 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 <code>malloc()</code> or some custom allocator like <code>libgc</code>’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.

For example, let’s say 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, <code>libgc</code>’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 <code>top(1)</code>...

(The worst thing is, 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 2004) 

* 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 <code>NRArenaShape</code> currently holds onto an <code>SPStyle</code> 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 <code>SPObject::hrefcount</code>).

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).

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

== Inkscape Experimental SVN ==

The <code>experimental</code> 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 <code>experimental/</code> 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 that’s okay.

When an experiment has matured to the point of being actually useful, please move it out of
the experimental module to someplace more appropriate. 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 <code>share</code> 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 <code>inkscape/share/</code> (except <code>AUTHORS</code> and <code>NEWS</code> 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 <code>/usr/share/flags-svg/</code>, 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 <code>src/</code>, 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 <code>.svgz</code> files: Is the server sending the right <code>Content-Encoding:</code> 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]]

Color Entry Widget

2013-01-05T16:10:06Z

Romain2Boss: /* Deal with full SVG 1.1 colors */

Here are the aims of this blueprint.

== Deal with full SVG 1.1 colors ==

The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications].

SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:

# Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
# Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
# Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.

The third case is proposed.

{| class="wikitable centre" width="80%"
|+ SVG 1.1 compliance matrix
|-
! scope=col | Input/Loaded color
! scope=col | SVG 1.1
! scope=col | Saved as
|-
| |
<nowiki>#FF00AA</nowiki>
| |
Yes
| |

|-
| |
<nowiki>#F0A</nowiki>
| |
Yes
| |

|-
| |
FF00AA
| |
No*
| |

|-
| |
F0A
| |
No*
| |

|-
| |
<nowiki>#FF00AADD</nowiki>
| |
No**
| |

|-
| |
FF00AADD
| |
No*
| |

|-
| |
rgb(255, 0, 170)
| |
Yes
| |

|-
| |
rgb(100%, 0%, 66%)
| |
Yes
| |

|-
| |
red
| |
Yes
| |

|}
<nowiki>* Kept for historycal reasons</nowiki>
<nowiki>** Kept for historycal reasons and as an hypotetical SVG 2 valid color format</nowiki>

== Prepare SVG 2 ==

Based on [http://www.w3.org/TR/SVG2/color.html SVG2]. The idea is to be more ''SVG 2 ready''.

=== sRGB colors ===

The HSL format is closed to RGB: no issue.

Some color named are added: no issue.

=== sRGB colors with alpha ===

RGBA and HSLA are added: no issue.

=== ICC and LAB colors ===

To be implemented?

== Keep the user value ==

Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.

The color sets in the entry is (chronologically):

# First, the color as written in the SVG file (if any)
# Then, if modified by the user (pasted or typed), the user value
# Then, if modified by the software (in case of multiple input widgets), the software value

If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.

== Help the user ==

If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).

If a color from the palette is dragged and dropped on the entry, it takes the color value.

[[Category:Proposals]]
[[Category:Widgets]]

Color Entry Widget

2013-01-05T16:09:17Z

Romain2Boss: /* Deal with full SVG 1.1 colors */

Here are the aims of this blueprint.

== Deal with full SVG 1.1 colors ==

The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications].

SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:

# Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
# Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
# Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.

The third case is proposed.

{| class="wikitable centre" width="80%"
|+ SVG 1.1 compliance matrix
|-
! scope=col | Input/Loaded color
! scope=col | SVG 1.1
! scope=col | Saved as
|-
| |
<nowiki>#FF00AA</nowiki>
| |
Yes
| |

|-
| |
<nowiki>#F0A</nowiki>
| |
Yes
| |

|-
| |
FF00AA
| |
No*
| |

|-
| |
F0A
| |
No*
| |

|-
| |
<nowiki>#FF00AADD</nowiki>
| |
No**
| |

|-
| |
FF00AADD
| |
No**
| |

|-
| |
rgb(255, 0, 170)
| |
Yes
| |

|-
| |
rgb(100%, 0%, 66%)
| |
Yes
| |

|-
| |
red
| |
Yes
| |

|}
<nowiki>* Kept for historycal reasons</nowiki>
<nowiki>** Kept for historycal reasons and as an hypotetical SVG 2 valid color format</nowiki>

== Prepare SVG 2 ==

Based on [http://www.w3.org/TR/SVG2/color.html SVG2]. The idea is to be more ''SVG 2 ready''.

=== sRGB colors ===

The HSL format is closed to RGB: no issue.

Some color named are added: no issue.

=== sRGB colors with alpha ===

RGBA and HSLA are added: no issue.

=== ICC and LAB colors ===

To be implemented?

== Keep the user value ==

Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.

The color sets in the entry is (chronologically):

# First, the color as written in the SVG file (if any)
# Then, if modified by the user (pasted or typed), the user value
# Then, if modified by the software (in case of multiple input widgets), the software value

If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.

== Help the user ==

If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).

If a color from the palette is dragged and dropped on the entry, it takes the color value.

[[Category:Proposals]]
[[Category:Widgets]]

Color Entry Widget

2013-01-05T12:18:08Z

Romain2Boss: /* Deal with full SVG 1.1 colors */ Add a SVG 1.1 compliance matrix

Here are the aims of this blueprint.

== Deal with full SVG 1.1 colors ==

The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications].

SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:

# Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
# Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
# Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.

The third case is proposed.

{| class="wikitable centre" width="80%"
|+ SVG 1.1 compliance matrix
|-
! scope=col | Input/Loaded color
! scope=col | SVG 1.1
! scope=col | Saved as
|-
| |
<nowiki>#FF00AA</nowiki>
| |
Yes
| |

|-
| |
FF00AA
| |
No*
| |

|-
| |
<nowiki>#FF00AADD</nowiki>
| |
No*
| |

|-
| |
FF00AADD
| |
No*
| |

|-
| |
rgb(255, 0, 170)
| |
Yes
| |

|-
| |
rgb(100%, 0%, 66%)
| |
Yes
| |

|-
| |
inherit
| |
Yes
| |

|-
| |
red
| |
Yes
| |

|}
<nowiki>* Kept for historycal reasons</nowiki>

== Prepare SVG 2 ==

Based on [http://www.w3.org/TR/SVG2/color.html SVG2]. The idea is to be more ''SVG 2 ready''.

=== sRGB colors ===

The HSL format is closed to RGB: no issue.

Some color named are added: no issue.

=== sRGB colors with alpha ===

RGBA and HSLA are added: no issue.

=== ICC and LAB colors ===

To be implemented?

== Keep the user value ==

Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.

The color sets in the entry is (chronologically):

# First, the color as written in the SVG file (if any)
# Then, if modified by the user (pasted or typed), the user value
# Then, if modified by the software (in case of multiple input widgets), the software value

If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.

== Help the user ==

If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).

If a color from the palette is dragged and dropped on the entry, it takes the color value.

[[Category:Proposals]]
[[Category:Widgets]]

Free Desktop Graphic Suite

2012-12-28T20:25:50Z

Romain2Boss: /* Resources that can be shared: */ Link fixed

Common interface for graphic programs on the free desktop.

Many artists use several applications in their workflow.
This includes using one program for photo editing, one for illustration and one for page layout.
To ease the user experience for someone using these apps, consistency in wording, looks and similar working tools needs to be adressed.

The three programs that will be adressed are:
* GNU Image Manipulator Program aka GIMP (bitmap image editing)
* Inkscape (scalable graphics illustration)
* Scribus (page layout)

== [[Common dialogs]] ==

== [[Tool consistency]] ==

== Resources that can be shared: ==
* Patterns (PNGs)
* Gradients (SVGs)
* Palettes (We need a standard here.) (suggestion: .xml format, based on .ai format (each text line with each colour name and its rgb, cmyk or whatever))
* Clipart (SVG/PNG)
:: We need some kind of universal, portable and standard svg rendering engine that can cope with InkscapeSvg. I think the ability to know that your source svg looks fine in the GIMP or several other programs on anyone else's computer would encourage people to use it a lot more (and would leapfrog the Adobe formats). It would also mean that when you used a vector image in another program you wouldn't have to rasterise it, so output would be better quality. [[User:Legio noctis|Legio noctis]] 14:56, 31 March 2010 (UTC)
* Icons
* Cursors
* Color Management
* Fonts
* Symbols
* Filters

To help manage these resources it would probably be wise to try and incorporate some kind of Thumbnail Browser into any such suite. Unfortunately there is no obvious choice of cross platform and open source Thumbnail browser.

:: Could all the open source projects agree on one location to store all these resources or links to them e.g. <tt>~/.graphicsresources</tt> or <tt> %appdata%\Graphic resources\</tt>?

Could this system be turned into a new open source project/standard of its own? For example, say we called it something like 'Pixelshare', for lack of a graphic-y sounding name. We could then say that every Pixelshare-supporting program makes sure that a <tt>Pixelshare resources</tt> folder has been established. This would then contain a set directory structure, e.g. there could be a database (XML?) of the various programs/files/whatever is needed for efficient operation. For example:
<tt>
/cursors 
/icons 
/images 
: /Inkscape 
::...insert here either actual files, shortcuts to files or database of files... 
: /GIMP 
information.xml 
/sound 
/videos 
</tt>

I suggest information.xml contains metadata about the programs, what they produce, formats etc, and the (potential) database inside the <tt>Inkscape</tt> folder actually contains information such as location of the image, when it was last opened, by what, created, by what, notes attached to it, whether it is a derivative of another file in the database etc.

I will try to return to this page and expand on my ideas more solidly. Someone had a grand vision creating this page, and I don't want to see it come to nothing. [[User:Legio noctis|Legio noctis]] 18:27, 1 April 2010 (UTC)

== A file sharing toolbar ==

Some mockups:

Standard toolbar:

[[File:Opengraphics_toolbar_mockup_1.png|800px]]

Toolbar with 'send to another application' menu open:

[[File:Opengraphics_toolbar_mockup_2.png|800px]]

Toolbar with 'my collections' menu open:

[[File:Opengraphics_toolbar_mockup_3.png|800px]]

Mini toolbar:

[[File:Opengraphics_toolbar_mockup_4.png|800px]]

Is this feasible? [[User:Legio noctis|Legio noctis]] 15:12, 31 March 2010 (UTC)

== [[Feature Requests]] ==

There are many features in the GIMP that Inkscape will want to copy such as the Dock Widgets for managing Palettes.

There are also some enhancements to the GIMP like this [http://bugzilla.gnome.org/show_bug.cgi?id=133030 request for a standard toolbar] that would be helpful for Inkscape users.

'''Links'''
* [http://www.nabble.com/Desktop-f822.html Open Source Desktop Forum] - a large forum hosted by [http://www.nabble.com Nabble] on big open source desktop projects such as [http://www.nabble.com/Gnome-f1226.html Gnome], [http://www.nabble.com/Xfce-f830.html Xfce], [http://www.nabble.com/Rox-f827.html Rox], [http://www.nabble.com/Etoile-f823.html Etoile].

* [http://software.newsforge.com/software/05/02/02/215259.shtml?tid=75&tid=131&tid=132 Article on free graphics software integration]

* [http://www.osnews.com/story.php?news_id=9658 '''Achieving higher consistency between OSS graphics applications''' - Bryce Harringtons article on the issue]

* [http://developer.gnome.org/projects/gup/hig/2.0/ Gnome Human Interface Guidelines]

* [http://usability.kde.org/ KDE Usability project]

* http://www.openusability.org/

* http://www.freedesktop.org/

* http://developer.gimp.org/standards.html

* [http://www.freedesktop.org/wiki/Standards_2ficon_2dtheme_2dspec Unified icon spec on freedesktop.org]

* http://openclipart.org/

[[Category:Developer Discussion]]
[[Category:Needs Work]]

Free Desktop Graphic Suite

2012-12-28T20:25:20Z

Romain2Boss: /* A file sharing toolbar */ Layout fixed

Common interface for graphic programs on the free desktop.

Many artists use several applications in their workflow.
This includes using one program for photo editing, one for illustration and one for page layout.
To ease the user experience for someone using these apps, consistency in wording, looks and similar working tools needs to be adressed.

The three programs that will be adressed are:
* GNU Image Manipulator Program aka GIMP (bitmap image editing)
* Inkscape (scalable graphics illustration)
* Scribus (page layout)

== [[Common dialogs]] ==

== [[Tool consistency]] ==

== Resources that can be shared: ==
* Patterns (PNGs)
* Gradients (SVGs)
* Palettes (We need a standard here.) (suggestion: .xml format, based on .ai format (each text line with each colour name and its rgb, cmyk or whatever))
* Clipart (SVG[[/PNG]])
:: We need some kind of universal, portable and standard svg rendering engine that can cope with InkscapeSvg. I think the ability to know that your source svg looks fine in the GIMP or several other programs on anyone else's computer would encourage people to use it a lot more (and would leapfrog the Adobe formats). It would also mean that when you used a vector image in another program you wouldn't have to rasterise it, so output would be better quality. [[User:Legio noctis|Legio noctis]] 14:56, 31 March 2010 (UTC)
* Icons
* Cursors
* Color Management
* Fonts
* Symbols
* Filters

To help manage these resources it would probably be wise to try and incorporate some kind of Thumbnail Browser into any such suite. Unfortunately there is no obvious choice of cross platform and open source Thumbnail browser.

:: Could all the open source projects agree on one location to store all these resources or links to them e.g. <tt>~/.graphicsresources</tt> or <tt> %appdata%\Graphic resources\</tt>?

Could this system be turned into a new open source project/standard of its own? For example, say we called it something like 'Pixelshare', for lack of a graphic-y sounding name. We could then say that every Pixelshare-supporting program makes sure that a <tt>Pixelshare resources</tt> folder has been established. This would then contain a set directory structure, e.g. there could be a database (XML?) of the various programs/files/whatever is needed for efficient operation. For example:
<tt>
/cursors 
/icons 
/images 
: /Inkscape 
::...insert here either actual files, shortcuts to files or database of files... 
: /GIMP 
information.xml 
/sound 
/videos 
</tt>

I suggest information.xml contains metadata about the programs, what they produce, formats etc, and the (potential) database inside the <tt>Inkscape</tt> folder actually contains information such as location of the image, when it was last opened, by what, created, by what, notes attached to it, whether it is a derivative of another file in the database etc.

I will try to return to this page and expand on my ideas more solidly. Someone had a grand vision creating this page, and I don't want to see it come to nothing. [[User:Legio noctis|Legio noctis]] 18:27, 1 April 2010 (UTC)
== A file sharing toolbar ==

Some mockups:

Standard toolbar:

[[File:Opengraphics_toolbar_mockup_1.png|800px]]

Toolbar with 'send to another application' menu open:

[[File:Opengraphics_toolbar_mockup_2.png|800px]]

Toolbar with 'my collections' menu open:

[[File:Opengraphics_toolbar_mockup_3.png|800px]]

Mini toolbar:

[[File:Opengraphics_toolbar_mockup_4.png|800px]]

Is this feasible? [[User:Legio noctis|Legio noctis]] 15:12, 31 March 2010 (UTC)

== [[Feature Requests]] ==

There are many features in the GIMP that Inkscape will want to copy such as the Dock Widgets for managing Palettes.

There are also some enhancements to the GIMP like this [http://bugzilla.gnome.org/show_bug.cgi?id=133030 request for a standard toolbar] that would be helpful for Inkscape users.

'''Links'''
* [http://www.nabble.com/Desktop-f822.html Open Source Desktop Forum] - a large forum hosted by [http://www.nabble.com Nabble] on big open source desktop projects such as [http://www.nabble.com/Gnome-f1226.html Gnome], [http://www.nabble.com/Xfce-f830.html Xfce], [http://www.nabble.com/Rox-f827.html Rox], [http://www.nabble.com/Etoile-f823.html Etoile].

* [http://software.newsforge.com/software/05/02/02/215259.shtml?tid=75&tid=131&tid=132 Article on free graphics software integration]

* [http://www.osnews.com/story.php?news_id=9658 '''Achieving higher consistency between OSS graphics applications''' - Bryce Harringtons article on the issue]

* [http://developer.gnome.org/projects/gup/hig/2.0/ Gnome Human Interface Guidelines]

* [http://usability.kde.org/ KDE Usability project]

* http://www.openusability.org/

* http://www.freedesktop.org/

* http://developer.gimp.org/standards.html

* [http://www.freedesktop.org/wiki/Standards_2ficon_2dtheme_2dspec Unified icon spec on freedesktop.org]

* http://openclipart.org/

[[Category:Developer Discussion]]
[[Category:Needs Work]]

CompilingSunSolaris

2012-12-28T20:23:45Z

Romain2Boss: Link fixed

= Compiling on Oracle/Sun Solaris =

==Compiling version 0.48.1==

here you can find how to build inkscape 0.48.1 on Solaris 10 (x86) 64 bit.

* Chose a prefix path where to install independent of Solaris' own libraries. In my example --prefix=/usr/local is used for all tools
* build GNU make and install it into /usr/local/bin
* Build one of the newest versions of gcc (I built 4.5.1). Before that install the needed libraries gmp, mpfr, mpc also with --prefix=/usr/local. Build gcc. Re-build the gmp/mpfr/mpc. Re-build gcc. After that you should have no further dependencies to /usr/sfw/lib which is important
* Edit the gcc specs to get a clean compilation independent if you use -m64 or -m32. To achieve this have a look at the *link_arch section where to put in additional -R/usr/local/lib and -R/usr/local/lib/64 (gcc configured to use Sun's ld).
* build pkg-config with --prefix=/usr/local --libdir=/usr/local/lib/64 for the following packages

For further installations I used a few environment variables:
<pre>
export PATH="/usr/local/bin:/usr/bin:/usr/ccs/bin"
export MAKE=/usr/local/bin/make
export CC="gcc -m64"
export CXX="g++ -m64"
</pre>

Build and install the following packages with
''./configure --prefix=/usr/local --libdir=/usr/local/lib/64 --sysconfdir=/usr/local/etc/64 --enable-shared''
<pre>
zlib-1.2.5
jpeg-6.2
gettext-0.17
libiconv-1.12
fontconfig-2.8.0
t1lib-5.1.0
freetype-2.4.4
render-0.8
libxrender-0.8.4
libpng-1.4.4 (cave: 1.5.x does not work with Inkscape!)
gsl-1.14
pixman-0.21.6
glib-2.28.3
glibmm-2.24.2
atk-1.32.0
pango-1.28.3
cairo-1.10.2 (rebuild pango after building cairo!!)
gtk+-2.24.3 (I avoided the very new version 3.....)
gdk-pixbuf-2.22.1
poppler-0.16.3 (use the additional flag --enable-xpdf-headers)
</pre>

Then make three small changes to inkscape's source:
<pre>
src/color-profile.cpp, line 8: Change "#include <sys/fcntl.h>" into "#include <fcntl.h>"

src/2geom/isnan.h, line 57: The mentioned "#include <cmath>" must be set

src/2geom/convex-cover.cpp, line 36: include these two lines (ok, quick and dirty....):
#undef INFINITY
#define INFINITY (__builtin_inff())
</pre>

Now configure inkscape as described above. You should get a clean compile. --[[User:Reinhard|Reinhard]]

==Compiling version 0.44==

This documents the changes that I needed to make Inkscape compile with gcc 3.3.2 on Solaris 8.

* install all hard dependencies
* provide a definition of ngettext (thread: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/15747/focus=15828)
* patch isfinite() like described here: http://opensolaris-br.org/osbr/index.php?option=com_content&task=view&id=34&Itemid=56
* src/dom/io/socket.cpp - FIONREAD undeclared: http://opendx.npaci.edu/mail/opendx-general/1999.06/msg00425.html (#include <sys/filio.h>)
* src/widgets/desktop-widget.cpp: replace round with rint
* src/trace/potrace/inkscape-potrace.cpp:288: error: `log2' undeclared (first use of this function)
:Add the following function to the file:
<pre>
// from http://groups.google.de/group/comp.lang.c/msg/8ae70d02495768f5?dmode=source&hl=de
double log2(double x)
{
static double ln2;
if (ln2 == 0.0)
ln2 = log (2.0);

return log (x) / ln2;
}
</pre>

* Now stuck here (gc6.7, gcc version 3.3.2):
<pre>
gc.cpp: In function `void Inkscape::GC::<unnamed>::do_init()':
gc.cpp:32: error: parse error before string constant
gc.cpp:32: error: `GC_noop1' undeclared (first use this function)
gc.cpp:32: error: (Each undeclared identifier is reported only once for each
function it appears in.)
gmake[2]: *** [gc.o] Error 1
gmake[2]: Leaving directory `/home/marquardt/Tools/inkscape-0.44/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/marquardt/Tools/inkscape-0.44'
gmake: *** [all] Error 2
</pre>

See also http://sourceforge.net/tracker/index.php?func=detail&aid=1516476&group_id=93438&atid=604306

I got the following patch for "gc6.7/include/gc.h" from Hans Boehm which fixes these problems with gc6.7:

<pre>
947a948
> extern int _end[], _etext[];
949,952c950
< # define GC_INIT() { extern int _end[], _etext[]; \
< extern "C" void GC_noop1(GC_word); \
< GC_noop1((GC_word)_end); \
< GC_noop1((GC_word)_etext); }
---
> extern "C" void GC_noop1(GC_word);
954,956c952
< # define GC_INIT() { extern int _end[], _etext[]; \
< extern void GC_noop(); \
< GC_noop(_end, _etext); }
---
> void GC_noop1();
957a954,955
> # define GC_INIT() { GC_noop1((GC_word)_end); \
> GC_noop1((GC_word)_etext); }
</pre>

With these changes, I got Inkscape running fine.
--[[User:Colin Marquardt|Colin Marquardt]]

==Compiling a 0.39 snapshot==

When trying to compile the CVS snapshot from 2004-05-27 with
gcc 3.3.2 on a
<nowiki>SunOS foo 5.8 Generic_108528-22 sun4u sparc SUNW,Sun-Fire-V240</nowiki>
machine, I had to fix a few things.

First, I installed the following packages:
<pre>
autoconf-2.59
automake-1.8.3
intltool-0.30
expat-1.95.7
libpng-1.2.5
libsigc++-2.0.3
glib-2.4.2
glibmm-2.4.2
atk-1.7.0
render-0.8
xrender-0.8.3
xft-2.1.2
pango-1.4.0
gtk+-2.4.2
gtkmm-2.4.2
</pre>

I configured Inkscape with the following switches:
<pre>
./configure --prefix=/home/foo/Tools/ --includedir=/home/foo/Tools/include CPPFLAGS=-I/home/foo/Tools/include
</pre>

Then "fix" stuff in the inkscape sources:

Uncomment "@INTLTOOL_DESKTOP_RULE@" in Makefile.

Use <inttypes.h>, not <stdint.h> in
<pre>
src/display/sp-canvas.h,
src/livarot/DblLinked.h,
src/livarot/LivarotDefs.h,
src/livarot/AVL.h,
src/livarot/Shape.h,
src/livarot/ShapeUtils.h,
src/livarot/Ligne.h
src/livarot/AlphaLigne.h
src/livarot/BitLigne.h
src/livarot/MyMath.h
</pre>
(see
http://www.lns.cornell.edu/public/COMP/info/autoconf/Header-Portability.html)

Replace round() with rint() according to
http://news.gw.com/freebsd.gnome/1237 in
</pre>
src/object-edit.cpp,
src/spiral-context.cpp
src/star-context.cpp
</pre>

fabsf() was undeclared (I just put in "fabs()", not sure if this is
correct) in
<pre>
src/sp-shape.cpp
</pre>
(see
http://gcc.gnu.org/ml/java/2001-01/msg00465.html).

Replaced fabsf(), floorf() and ceilf() with fabs(), floor() and ceil() in
<pre>
src/display/nr-arena-shape.cpp
src/display/canvas-bpath.cpp
src/display/sp-ctrlline.cpp
src/libnrtype/nr-rasterfont.cpp
src/livarot/AlphaLigne.cpp
src/livarot/BitLigne.cpp
src/livarot/Ligne.cpp
src/livarot/PathOutline.cpp
src/livarot/ShapeMisc.cpp
</pre>

isfinite() is undeclared, use
<pre>
#include <ieeefp.h>
</pre>
and finite() (see http://devrsrc1.external.hp.com/STKS/impacts/i61.html) in
<pre>
src/display/bezier-utils.cpp
</pre>

Need to include
<pre>
#include <ieeefp.h>
</pre>
in
<pre>
src/libnr/nr-svp.cpp
</pre>

Missing strcasestr() used in libnrtype/nr-type-directory.cpp. I just
use the internal version for WIN32 given in the file.

<pre>
In file included from /home/foo/Tools/include/X11/extensions/Xrender.h:33,
from /home/foo/Tools/include/X11/Xft/Xft.h:47,
from libnrtype/nr-type-xft.cpp:16:
/usr/openwin/include/X11/Xutil.h:56: warning: ignoring #pragma ident
/usr/openwin/include/X11/Xutil.h:117: error: 'Bool' is used as a type, but is
not defined as a type.
/usr/openwin/include/X11/Xutil.h:120: error: 'Pixmap' is used as a type, but is
not defined as a type.
/usr/openwin/include/X11/Xutil.h:121: error: 'Window' is used as a type, but is
not defined as a type.
[...]
</pre>
etc. Fixed this by adding #include <X11/Xlib.h>
before including Xft.h in src/libnrtype/nr-type-xft.cpp.

`bind_textdomain_codeset' undeclared in src/main.cpp and src/inkscape.cpp. Just copied the definition in that
file outside the ifdef.

`fpresetsticky' undeclared (autoconf seems to have checks for it. Solaris has fpsetsticky() when ieeefp.h is included.)

No rule for target inkscape.desktop - just created an empty rule.

DONE! It runs on Solaris! Yay! :)
--Colin Marquardt

=See also=
*[[Compiling Inkscape]]

[[Category:Developer Documentation]]

Animation-(Timeline)

2012-12-28T20:20:48Z

Romain2Boss: Link fixed

{{DevDiscussion}}
[[Animation|Back to main page for animation]]

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

Free (or Open Source)

* [http://antimatter15.com/wp/ajax-animator/ Ajax Animator] is a FUNCTIONAL web-based (ajax) free-software clone of the flash interface, and uses a SVG based format for saving and compiling animations (http://osflash.org/ajaxanimator)
* QFlash is a FUNCTIONAL free-software mock-up of the Flash 4 interface, which can import SVG files but not edit them. (http://qflash.sourceforge.net) (last update 2009/07/17)
* F4l is a non-functional free-software mock-up of the Flash 4 interface.(http://f4l.sf.net/)
* [[LimSee2]] (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (visible-source limited-use license)
* Spalah Flash (http://sourceforge.net/projects/spalah/) (not to be confused with Spalah CMS) "is a GTK2/GNOME2 based application for generating Macromedia SWF and [[W3C]] SVG animations." The GUI is today minimalist but the author is trying to integrate it with inkscape. See http://spalah.sourceforge.net/?p=25
* Jahshaka (http://www.jahshaka.com/) multi-platform QT animation program powered mostly by OpenGL (GPL)
* Ktoon (http://ktoon.net/) is a 2D Animation Toolkit designed by animators for animators, focused to the Cartoon Industry. (GPL)
* SMIL 2.1 player: http://www.cwi.nl/projects/Ambulant/distPlayer.html (GPL)
* [[Synfig]] ([http://www.synfig.org/ link]) is a film-quality 2D vector animation editor and renderer. It features image morphing between drawings and output animation that is resolution independent both visually and temporally. (GPL)
* Pencil (http://www.les-stooges.org/pascal/pencil/index.php?id=Home) vector and bitmap free animation package using Qt toolkit run on Ubuntu ([http://packages.ubuntu.com/search?keywords=pencil&searchon=names&suite=all&section=all reference]), Win32 (XP and works fine on wine), and MacOSX. Simple but already powerful basic animation. It uses blender like time line with multiple layers and Author plan to export SVG.
* Blender3D (http://blender.org/) is a 3d (eq. vector) animation program featuring [http://wiki.blender.org/index.php/Manual/Animation_Basics key frame, motion curve, path animation] using [http://wiki.blender.org/index.php/Manual/Ipo_Curves_and_Keyframes interpolation (IPO) curve editing] combining with [http://wiki.blender.org/index.php/Manual/Shape_Keys shape keys] and [http://wiki.blender.org/index.php/Manual/Animation/Lattice_Animation deforming by a lattice] (GPL)
* [http://gimp.org Gimp] the bitmap editor and it's included animation script for gif is really minimalistic and frame based
* [http://gimp.org Gimp-GAP] (Gimp Animation Plugin) is a gimp plugin has some good interfaces for managing movements of objects (menu video=>movepath), layer management and apply effects along animation. A powerful onionskin management, and notions of clip/storyboard, but could be slow in complex cases and slow computers.
* [http://www.thebest3d.com/dogwaffle/free/index.html PD1.2] Free program for digital painting and limited animation

Non-Free (Fee Based, or Proprietary)

* CSS3 Animator + HTML5 - http://www.sencha.com/products/animator/
* [[PICMO]] - http://picmo.com/en/features.html
* [[MacromediaFlash|Adobe Flash]] (Formerly Macromedia Flash) is a good non-Free example.
* Ikivo Animator is a good non-Free example producing SVG Tiny animations (http://www.ikivo.com/animator/index.html)
* Macromedia Director prior to version MX had a different interface (http://www.rice.edu/fondren/erc/howto/director.html) which I prefer(ed) over Flash
* Anime Studio, formerly known as [[Moho]] (http://www.e-frontier.com/article/articleview/1913/1/793?sbss=793) a non-free example. (Written in Java.) Features skeletal animation ([http://www.e-frontier.com/article/articleview/1918/1/800?sbss=80х, unique bone rigging for 2D]) and automatic tweening of vector operations, [http://img.osnews.com/img/2547/moho4-rh.png view screenshot].
* Bob Sabiston's proprietary animation software http://www.flatblackfilms.com
* Powerpoint (http://office.microsoft.com) has an easy but basic interface. No flash killer, but some nice ideas.
* The Tab (http://www.the-tab.com/) Another non-free example that features elegant systems for parent-child animation and a very interesting feature that is designed for pseudo-3D camera moves.
* SVGDeveloper (http://www.perfectsvg.com/) is a non-free SVG authoring tool with animation support.
* [http://www.tvpaint.com TV Paint] is a non-free bitmap based compositing and animation package. It works with a timeline and layers. Notable feature is the onion skin "mixer", which let's you adjust the brightness of multiple frames before and after the current one.
* [http://www.toonboom.com/ Toon Boom] is a non-free vector based frame by frame animation package. It simulates a lot of the tools familiar to traditional animators, such as a dope sheet, field charts and more. Has two modes, one for drawing "cells" and one for placing them in front of a virtual camera in basic 3D space.
* [http://www.thebest3d.com/ PD 2 through PD4] A series non-free programs combining various capabilities for digital painting and animation. The high end program allows creation of special effects
* Mewafilm ( http://www.mewatools.com/images/curveeditor_mainwindow.png , http://www.mewatools.com/screenshots.html )

==== Fantavision example ====
Back in the '80's there was a program on Apple IIE (Amiga and MS-DOS too) called "Fantavision". It allowed one to create vector artwork (although I didn't understand at the time that that was what it was called) and animations. It allowed one to create frames of animation where you manually repositioned, recolored, scaled, rotated etc. the objects from one frame to the next. However, it then automatically interpolated frames between the 2 frames (the number of interpolated frames was configurable) such that it create a smooth transition of the object moving from one frame to the other. The effect was very similiar to the "Morphing" effect for raster graphics (popularized in a Michael Jackson video, I believe). That is, the system calculated the trajectory of "Key Points" of the objects from one frame to the next. This process is often called "Tweening" (a term used by Adobe Flash). [[Sketch|Skencil]] (formerly known as [[Sketch]]) supports this functionality and describes it as "Blending".

I guess what I'm saying is that I think a nice interface to create animations would be similiar. So to animate you would do the following:

* Draw the initial SVG Image

* Increment Frame (from say 1 to 20)

* Reposition the elements in frame 20 (including scaling, color changes, adding removing objects, etc, etc, etc)

* System would then calculate a trajectory for each key point from frame 1 to frame 20. Trajectories would be calculated for things like:
** Each "node" of an object
** Color
** Transformation Matrix
** etc

* You could display/manipulate the trajectories (using the trajectory editor shown above by the original creator of this topic)

* The system would then store the animations using SVG trajectories and the "Key Points" would be the frames you manually created

:So, to create say a 100 frame animation, one might only need to manually create/modify 10 frames and the system would interpolate the additional frames as necessary.

* Also, once the system interpolated frames it would allow you to manually modify the interpolated frames creating further "Key Points" and allow further refinement and interpolation.

NOTE: 3D apps such as blender also use a technique like this, which I think is most widely known as "keyframe animation" or simply "keyframing". However, many such systems tie the keys too closely to actual animation frames, and this creates problems when the frames-per-second rate changes. Particularly in the case of vector apps which are not so low-level as bitmaps and animation frames, I would suggest that frames should be as abstract as possible.

Having key positions in simple percentages of the total animation time might be a better solution. This would also need to be a global/local system, of course: animated objects would have their own animation time specified when inserted into a larger document. A character's walkcycle would end at 100%, but in the larger animation, it would perhaps only be 5% of the total time, yet repeating as the object moves across the screen.

One issue with this abstraction of frames might be that important animation effects do not occur exactly within frames: small things could be mistimed, or simply missed altogether. If you set the frame rate too low, this would be an obvious side effect, so it's not necessarily a problem
that Inkscape should try to fix. On the other hand, a few things could be done to ease this. For instance, "snapping" animation events to frames when exporting (thereby slightly altering the timing), or perhaps just warning that certain animation events are not visible at such a low frame rate.

Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)

ANOTHER NOTE: Interpolation does not necessarily occur along straight lines and linearly in time. Paths are already part of Inkscape, so points could move along paths; also the time-length graph can be something like a path, instead of a straight line.

==== Jahshaka example ====

I have used jahshaka for a small animation. This was my first real experience with animation. Thought rough, jahshaka is all about key frames and setting properties for those key frames.

Things I liked

* Key frames are on a per object basis
* When an object is selected you can quickly move from one key frame to another
* Property values for rotation can span beyond 0 and 360, permitting one to set three or more complete rotations within two key frames. I think this kind of feature could be used for all bounded values (like color, transparency and so on). Is this compatible with SVG or should it be an artifact?
* Representation of property values on a time line graph. This functionality was still not very usable, but being able to interact through that kind of object could be very useful (see below).

Things that it lacks (and Inkscape shall have)

* Possibility to copy animation properties from one object to another (say copy color animation, or whole animation).
* Possibility to modify a property value for all key frames at once (eg. translation of object for all key frames or a selected group). I think this could happen through the value = f(time) graph metioned above. You could select points (representing keyframes) and move them up (more), down (less), right (sooner). This graph could be organised by property set (color, position). I think this kind of graph would be very close to SVG animations tag.
* A macro that helps sets common effects (like blinking for example, or crossing the screen).

==== Bob Sabiston Example ====
Bob Sabiston's animation software is an amazing vector-based package that stores line width within the points that make up a line -- derived from a tablet pen. usually in a simple stroke there could be a hundred data points storing width information. Then in the next keyframe, a line from a previous key is selected and re-drawn restricted to the same number of points. The software allows the points to be "repositioned" as you watch their previous locations be re-positioned. When you run out, the line ends automatically. This information is interpolated in tweening frames to change shape, width, and position, but retains the same number of data-points. See the film "Waking Life" for the making-of video for a demonstration. Also visit his website for examples of its capabilities converted to Flash. http://www.flatblackfilms.com

==== Other thoughts ====

Suggestion from someone else: working like [[CinePaint]] (compared with Gimp), with each frame independently from each svg document (working like this or providing this feature) - providing vectorial edition quality we can't get on apps like Macromedia Flash or any other (maybe [http://www.toonboomstudio.com/ ToonBoom] or Moho) - allowing us to make our work fast publish without further lack of quality.
(One more suggestion about it: being able to convert .swf to .svg sequence (or animated .sgv) and vice versa.)

It is suggested that there be basically two modes: Local (Object) mode and Global mode. Below is a picture showing a very rough design of the local mode:

http://www.inkscape.org/wiki_uploads/anim_gui1.png

In local modes, all properties of the object editing will be shown on a timeline, and one can create and edit frame within the timeline. Then one may assign different value of that properties on different timeline, or make it change linearly, or nonlinearly :)

----

Animation support in Inkscape offers great new opportunities. Here are some points that I think are important to keep in mind when adding animation to the GUI:

* ''Originality'' Don't do as other do - except it's the best way.
* ''Simplicity'' Animation should not stand in the way of the user. Only show as much as necessary to perform a certain task, and do things in the most natural way.
* ''SVG-Orientation'' SVG animation is different in some ways. The UI should reflect this, and not reassemble concepts of tools that just work differently. E.g.,
** SMIL animation has no concept of frames. So we don't need a frame-based timeline, but a time-based one.
** SMIL animation in general is to animation what vector graphics is to graphics: It's declarative and object oriented. So one doesn't animate a scene, one animates objects on a scene, etc.
* ''Coherence'' The animation UI should reassemble concepts that Inkscape users are already familiar with:
** Animation timelines can in some contexts be treated as paths that one can add points to (keyTimes). Or one can control animation timing with splines (keySplines).

I composed a mockup that reflects the above mentioned characteristics to some extend:
http://www.uni-bremen.de/~felwert/inkscape/Animation01.html

==== Powerpoint Example ====
You select an object and add types of animation. These are listed in the custom animation pane. They can be set to occur all at once, one at a time, onclick, with previous or after previous. A number appears next to each object in the editing window when the object has animation applied to it, representing the sequence of the animations. When an object has an Entrance type animation added to it as the first animation, it will not appear on screen until the timeline reaches this point. animations can be linked together to create quite complicated sequences.

==== Onion Skinning ====
Onion skinning is a standard animator tool, previous or next frames (sometime both) are displayed under the current frame with differrent color, or less contrast, allowing to understand wich drawing the animator is actually working on, and wich frame is 1 step or 2 step before or after the actual frame.

This can easily be implemented using transparency parameter of layer, and automatize selection of layers to be displayed, parameters following a specialized gui entries.

Onionskin in gimp-GAP is a good example of what should be a minimal requirement. that is managin backword, forward and both direction onion skin, with variable visiblity increase decrease. Color changes on onionskinning could be another useful option to increase visiblity of different frames, as generally the onionskinning is done at the sketching animation step (meaning mostly grey or black & white drawing)

[http://en.wikipedia.org/wiki/Onion-skinning Onion skinning on wikipedia].

==== Interactive ====
I have started using svg to develop interactive displays. Having used several other svg tools currently on the market, I am interested in a more generic implementation that doesn't have animation effects get in the way of interactive controls.

==== Playback of Construction Steps ====
We, at [http://www.classapart.org Class Apart] ( www.classapart.org ), plan to use Inkscape in a manner similar to the classroom whitebord to create taught lectures and record the screen in an mpeg movie. The problem is that raster based formats would take about 50 MB for an hour of content, and does not go very well with our unstated goal of getting a whole course on a cd or all courses of a semester on one dvd. It would be great if we could store the construction steps of the svg keyed against time while recording. Then while playback we can patch the svg dom with the steps as needed, using something similar to smil script. How does one go about implementing this? We could find some members willing to implement.

==== Using Bones ====
Anime Studio (and all 3D animation software) uses bones to animate with. In Anime Studio you draw up a basic skeleton and then attach the drawing to the bones This is done automatically based on the distance between the bone and the points on the curve. You can then move, rotate or scale the bones to animate the characters. You can store these values per frame, and have the computer interpolate them. This is a much faster way to work than to interpolate the points on the drawing directly. 3D software is probably a better reference here than Anime Studio. Usefull features include:
* Weighting of individual points to bones
* Combining tweening and frame by frame animation. To create replaceable mouths, rotating heads and more.
* Inverse kinematics, to speed up animation. With it you can grab the hand of a character and have the arm follow, rather than rotate the upper arm and lower arm separately to move the hand.
* Constraining. Making one bone follow another, limiting the movement of a bone and so on.
* Graph/Curve editor. A time based editor with b-splines representing the individual move, rotate and scale transformations. This gives the animator great control over the animation.

==== Drawing Frames ====
Toon Boom, Plastic Animation Paper, TV Paint, Animo and traditional 2D animation on paper, all use individual drawings per frame. This gives you by far the best control when doing character animation, but at the cost of a lot of work. Features that are needed for traditional 2D animation to work well include:
* Onion skinning, preferably multiple levels back and forward and adjustable transparency.
* Dope sheet or timeline where you can move frames back and forth and repeat/hold frames.
* Cut-outs, where you move a whole or part of a frame to a different position for tracing on another frame.
* Some way to do rough sketching. Plastic Animation Paper is a good example here, though it's bit map based. With a tablet it gives you pencil like feel when drawing, giving darker lines the harder you press. This helps the animator "find the line". It should be possible to do in vectors if using a central line that stores the pressure along each point (width and/or opacity), rather than an outline.
Combining tweening animation and frame by frame animation can in many cases give the best results.

==== SMIL Animation (SVG Animation) vs SMIL Timing and Sync ====
What should the scope of Inkscape's animation capabilities be?
Many people are talking about mimicking other software's ability to do frame-by-frame animation and cartoon animation (particularly Flash's).

SVG inherits from [http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html SMIL's "Animation" module], with a [http://www.w3.org/TR/SVG11/animate.html#RelationshipToSMILAnimation few added animation controls] for animating a path, transform, or animating along a path.

SMIL's animation module however does not provide for elements to begin or end, although we can fake this by having elements initially invisible, and animating their visibility to 'true' during their lifespan.

While this may be feasible for a few long animations (ie, scenes), will it work for someone attempting to do traditional 2D (even Flash-style) animation? Said hypothetical user, while they may take some advantage of shape and motion tweens, will also likely need to replace the entire drawing when elements of the drawing (characters et al) change their logical structure (a motion requiring a line to appear or disappear). If this is to be supported, Inkscape will need some VERY fast code for switching visibility on-and-off during previewing, as it may be considering the visibility of hundreds if not thousands of graphic elements at a time, to over a dozen times per timeline-second.

Will other SVG viewers be able to handle that, too, or is it a special use of SVG that's not central to the aim of Inkscape?

[http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html SMIL's "Timing and Synchronization" module] supports elements that allow for massive numbers of sequential images or animation elements, as well as defining animation attributes for begin/end/duration timelines. While it's not part of the SVG spec, would this be something Inkscape should look into implementing, or even proposing as an addition in a revision of the SVG spec?

==== A new idea I think ====
I can't let go of an idea I'll try to explain as clearly as possible. How about having Inkscape calculate frames in a certain resolution (say 1 to 28 a second) and depth (number of frames displayed) and displaying a number of subsequent frames in over or underlay (transparancy is possible, but eats time) with fading outline colours to depict passing time.

You set either the framerate (calculated) and begin and end frame in time, or select from begin and end instances of an animate. Alternatively, selecting paths from a list and showing all objects following that path. That way you could (if hardware allows) browse through your animation and look for hiccups in its motion.

The same interface depicting frame number could be used to display page numbers in a multi page document. Would be nice in combination with an object manager similar to Coreldraws, enabling to select an object in either defs and see what happens to it in the animation, a path or all USE, XLINK etc.

Using some shifting switch to go forward and backwards in time to follow your animation (or mouse gesture, but button press would be more useful). That way you have a direct interaction with the user and the document.

::I strongly disagree with a model, that bases on frames. SVG is and should be only time-dependent. Start-duration-end. --[[User:VonHalenbach|SvH]] 16:41, 28 February 2009 (UTC)

====Custom Keytime-based Timeline====

Not based on frames at all, although the ability to select a frames-per-second setting allows for a grid that could be used to emulate frame-based animation. I posted the concept along with a mockup on the [[SpecSVGAnimation]] page. ("An example of the third..." to the end of that section)
--[[User:JadeMatrix|JadeMatrix]] 16:32, 6 February 2009 (UTC)

::In the animation, frames are of no use. You only edit the moving objects in time and when you are ready, you let it render into a number of frames or define, how much frames per second you need. But that is all after the file is saved as svg. Then the rendering can start. Construction and rendering are two different things, which we don't want to mix up in this process. --[[User:VonHalenbach|SvH]] 16:49, 28 February 2009 (UTC)

::Responded over at [[SpecSVGAnimation]].--[[User:JadeMatrix|JadeMatrix]] 04:43, 4 March 2009 (UTC)

== SVG-animation THE object-oriented approach to animation ==
SVG-animation is compared to a framebased movieeditor like comparing turbo pascal with c++. These are two different worlds or paradigms. You have to relearn your language, because you have to forget to think in frames. Every object, Line, Rectangle, Path has his own time and space. You could move everything on one single path or give every object a different path to move on. Or you could change the size or its color over time. SVG-animation is designed to get animation on mobile devices. Inkscape should focus on those for animation. We certainly need a global-timeline, on which all animated things get a colored representation (a color bar for each object) of their movement in time. There are already programs to render animated svg into a number of png's or animated png. Inkscape must only be conformant to the svg-standard. --[[User:VonHalenbach|SvH]] 17:13, 28 February 2009 (UTC)

Announcement to Sodipodi

2012-12-28T20:18:41Z

Romain2Boss: Link fixed

=== Announcement to Sodipodi Project of the Inkscape Project ===

Nathan, mental, Ted and myself have decided to embark on our own direction
with the Sodipodi codebase. We have attempted to do this as part of the
Sodipodi project, but we believe we need to try out a new project structure
to have the freedom to be able to explore some approaches radically different
from Sodipodi.

We have recently reworked the Sodipodi codebase to build with a C++ compiler and
renamed it 'Inkscape'. We have also set up a project on Sourceforge and established a new
website at http://www.inkscape.org.

Our goal is the creation of a fully SVG-compliant 2D graphics editor:
* Full SVG (plus XML, CSS2) compliance
* Core written in C++
* Gtk-based user interface following the standards set out in the GNOME HIG
* Emphasis on a small core plus modular extensions for features (a la Mozilla Firebird)
* Open, community-oriented development processes that welcomes experimentation
* Baseline is the Sodipodi-Hydra codebase
* Removal of dead code

We are aiming specifically for a general purpose XML/SVG graphics editor, and as a consequence will emphasize features that tend to fall outside the Sodipodi target userbase. We would like to welcome anyone who'd like to
do some experimentation to participate with us. Subscribe at
http://lists.sourceforge.net/lists/listinfo/inkscape-devel

We also intend to seek use of third-party libraries in preference to custom code (where reasonable); specifically, we are exploring Cairo (formerly Xr), libcroco, Pango, the core Gtk widgets, but also other existing and widespread facilities. The extension architecture is partly intended to minimize library dependencies in the core.

-- Bryce

[[Category:Wiki Attic]]

SpellCheckForTextNodes

2012-12-28T20:18:10Z

Romain2Boss: Link fixed

= Introduction =

It is often desireable to spell check text nodes in an inkscape document.

The stable release of inkscape currently (0.41) does not support this. You will have to open the xml in a text editor and search and spell check the text nodes there.

The code in CVS (0.42pre) has support for spell check in that it marks misspelled words in the "Text" tab in the "Text and Font" dialog if you compile with [[WITH_GTKSPELL]]. It will then use gtkspell to check the text nodes. gtkspell seems to pick its language according to [[LC_MESSAGES]]. Thus, if you have [[LC_MESSAGES]]=fr_FR.UTF-8 in your environment it will presumably use "fr_FR" for spelling.

The desired solution is for inkscape to use the xml:lang attribute of the text node to do the spell checking against the proper language.

= Implementation =

There are two ways to implement this:

# allow one language per text element
# allow any number of languages per text element in that you let the user select a region in the text and define a language for that.

There are two parts to an implementation:

# an user interface to be able to set the xml:lang attribute for a text node
# make sure gtkspell makes use of this information for spell checking

== User interface changes ==

=== One language per text element ===
If you allow only one language per text element the ui is fairly straight forward. The Text and Font dialog would contain an element to specify the language for the current text element.

The global language setting (the default language if you like) could be set in the Page tab of the document preferences dialog.

=== Multiple languages per text element ===
If you allow setting the language for any selection of text you could maybe use a combo box or a combo box entry in the text tool bar where you could specify the language for the current selection (or for the current text element if there is no selection). This would also show the current language setting of the selected text element or the selected region.

The global setting would again be in the document preferences dialog

=== Which languages in the combo box ===
The question is which languages should the user be able to choose from in the combo box? This question has an impact on the widget choice: for given small set of languages the combo box makes most sense. For a big number of languages the combo box entry might make more sense. There is basically two arguments:

* The user should only be able to choose from the installed dictionaries. Anything else doesn't make sense as she cannot do spell check for other languages anyway.
* The user should be able to choose from any existing language because this is a requirement for inkscape to claim to be a conforming svg authoring tool! (see http://www.w3.org/TR/WAI-WEBCONTENT/#gl-abbreviated-and-foreign)

The combo box entry is not nice as it might confuse novice users (too much choice, possibility of non-valid entry) however to be conforming we probably need a combo box entry. [http://www.gtk.org/plan/2.6/ Gtk+ 2.6] has an improved [[GtkComboBox]] which can handle trees, so the languages could be set up in a tree where the first level would be the first character of the language (this should allow us to handle the many languages case gracefully without having to resort to manual entry of e.g. de_CH).

=== Inheritance ===

A more tricky part would be to allow for some kind of inheritance where you specify a default language and have the possibility to override this in specific text nodes. I would suggest to leave this feature out for now.

== Code changes ==
The second point seems to be fairly straight forward. There are some comments and a todo on how to do this in src/dialogs/text-edit.cpp (search for [[WITH_GTKSPELL]]) where it says:

/* todo: Use computed xml:lang attribute of relevant element, if present, to specify the
language (either as 2nd arg of gtkspell_new_attach, or with explicit
gtkspell_set_language call in; see advanced.c example in gtkspell docs).
sp_text_edit_dialog_read_selection looks like a suitable place. */

However it might be more desireable to set the [[GtkTextTags]] in sp_text_edit_dialog_read_selection. According to pjrm this seems to have the desired effect.

It seems that pjrm has basically hacked up a solution for the second part but has apparently hit a bug in gtkspell where it apparently ignores the language info from language [[GtkTextTag]]'s in preference to querying locale (see the second irc log for all the details).

= irc log =

Here is the log of the chat on irc:

(11:15:23) egli: but I was wondering if there was a way to spell check the text objects?
(11:17:06) egli: or in case it was not built in I was wondering how complicated it would be to add
(11:18:02) [[SkoZombie]]: If you go to "Text and Font" and click on "Text" then it'll hilite possibly mispelt words
(11:18:15) [[SkoZombie]]: but i'm runnong the latest CVS version, 0.41 (latest stable) might be different
(11:18:27) egli: hm, let me check
(11:21:26) egli: you are talking about the "Text" tab in the "Text and Font" Dialog, right? It doesn't hilight any words despite the fact that they are in german :-/. Yes this is 0.41
(11:23:16) egli: I presume the UI should have a possibility to specify the language of a text object.
(11:23:36) egli: I guess I'll need to check out CVS
(11:23:41) egli: thanks [[SkoZombie]]
(11:23:43) [[SkoZombie]]: it must be a 0.42pre feature
(11:23:59) [[SkoZombie]]: sorry i can't be of more help, but yes, a spell checker would be a nice addition :)
(11:24:32) egli: I'll see if I find time to look into it
(11:28:28) ^-: [pjrm] spell checking may depend on having gtkspell and possibly related libraries installed.
(11:28:38) ^-: [pjrm] and aspell
(11:28:57) ^-: [pjrm] Is there any message on standard error?
(11:30:30) ^-: [pjrm] gtkspell seems to pick its language according to [[LC_MESSAGES]]. Thus, I have [[LC_MESSAGES]]=fr_FR.UTF-8 in my environment, and I get “gtkspell error: aspell: No word lists can be found for the language "fr_FR".” on stderr when I open the Text & Font dialog box.
(11:31:31) ^-: [pjrm] (Of course inkscape ought to tell gtkspell what language to use according to xml:lang attributes, but that isn't implemented.)
(11:33:21) ^-: [pjrm] Doesn't seem to be in 0.41.
(11:33:41) ^-: [cornelius] does it requires to have gtkspell-devel installed while compilling inkscape?
(11:33:47) ^-: [cornelius] *require
(11:35:38) ^-: [pjrm] Looks like it: dialogs/text-edit.cpp has "#ifdef [[WITH_GTKSPELL]]"
(11:36:06) ^-: [cornelius] ah ok, so that's why I don't have got it enabled :)
(11:36:25) ^-: [pjrm] configure.ac tests if pkg-config --exists gtkspell-2.0
(11:37:30) ^-: [cornelius] /me will more look and less ask later
(11:38:11) egli: pjrm: hm, you're saying that the svg:text node has a xml:lang attribute?
(11:38:44) ^-: [pjrm] yes
(11:39:01) egli: hm I don't see it if I open the xml editor
(11:39:15) egli: do I have to add it manually for the moment?
(11:39:22) ^-: [pjrm] yes
(11:39:30) egli: ah :-)
(11:39:30) ^-: [pjrm] was just about to say: "has" meaning "allows"
(11:40:06) egli: so the spell check feature would require a gui which actually add the xml:lang attr to the text node?
(11:40:45) ^-: [pjrm] well, as i say, inkscape doesn't yet look at xml:lang attributes.
(11:41:51) egli: ok, I understand that, but in order to have spell check for different languages this would have to be implemented, correct?
(11:41:52) ^-: [pjrm] I'm just saying that xml:lang attributes (if present) would be a better choice of language for the spell checker than querying the environment for the current user's chosen locale
(11:42:05) egli: ok, yes, I agree
(11:42:24) ^-: [pjrm] re "required", you could always restart inkscape with a different locale :)
(11:43:33) egli: hehe, my birth announcement was bilingual
(11:44:06) Uraeus [~cschalle@core.fluendo.com] entered the room.
(11:44:08) ^-: [pjrm] the comment in src/dialogs/text-edit.cpp (search for [[WITH_GTKSPELL]]) gives more detail on how to implement
(11:45:36) ^-: [pjrm] it doesn't mention how to code the gui for controlling xml:lang attributes. That's independent. I don't think it's too hard, apart from the desirability of distinguishing between "unspecified, just inherit" and providing explicit value.
(11:49:37) egli: ah, pjrm, you're making me curious, I'm checking out the source from CVS now
(11:53:19) ^-: [pjrm] :)
(11:54:08) egli: inkscape is the module I want, right?
(11:55:31) ^-: [pjrm] yes
(11:55:37) egli: ok
(11:55:50) ^-: [pjrm] see also gtkspell docs
(11:56:49) ^-: [pjrm] hmm, i wonder if it would suffice to copy xml:lang attributes into pango markup in the text widget
(11:58:03) ^-: * basic has left: Replaced by new connection
(12:01:46) egli: pjrm: I found the relevant code snippet. I'll have to look at the gtkspell docs
(12:02:47) ^-: [pjrm] there's a gtk_text_buffer_insert_with_tags function we could probably use instead of gtk_text_buffer_set_text in sp_text_edit_dialog_read_selection
(12:06:58) egli: ok, I'm totally new at this. You're outlining two ways now: either pango markup in the text widget or the gtk_text_buffer_insert_with_tags function. Or do they amount to the same
(12:10:07) ^-: [pjrm] apparently one can't directly set pango markup
(12:10:47) ^-: [pjrm] the [[GtkTextWidget]] converts its [[GtkTextTag]] stuff to pango stuff
(12:11:07) ^-: [pjrm] (according to my brief glance at text_widget_internals.txt.gz just now)
(12:11:56) ringerc left the room (quit: "oops, someone let the magic smoke out.").
(12:13:16) egli: ok, I want to put this stuff into the wiki so I do not forget. Where do I put this best? just create a new page in the wiki and link to it from the newfeatureProposals?
(12:13:52) ^-: [pjrm] There's a feature request item in the tracker: see one of the buttons on the left of www.inkscape.org
(12:17:17) egli: oh, this tracker thingy. I'd rather put this discussion into the wiki. But I dunno how the inkscape devs work
(12:26:25) [[SkoZombie]]: egli: they can always remove it from the wiki if they think its inappropriate for whatever reason
(12:26:59) egli: ok, thanks [[SkoZombie]]
(12:55:07) ^-: [pjrm] Setting [[GtkTextTags]] seems to have the right effect.

Updates again from irc:

(14:18:43) egli: I don't quite understand what pjrm means when he says "Setting [[GtkTextTags]] seems to have the right effect". Does that mean he actually hacked up a solution that uses the xml:lang attribute for spell checking?
(15:14:42) ^-: [pjrm_home] egli: When I said that, all I'd implemented was applying a single tag over the entire buffer with a hard-coded language code "fr_FR". When I ran inkscape in a C locale and typed text with mixed english & french, the english words were underlined as "misspelled".
(15:16:16) ^-: [pjrm_home] I've since coded a little more. However, even if I could finish the feature tonight, I don't know whether it would be applied for 0.42 or not.
(15:17:34) ^-: [pjrm_home] It's a nice touch, but it has a reasonable chance of introducing bugs (e.g. mismanaging memory, possibly even causing crash bugs), so it might be considered that the risk outweighs the goodness of this feature.
(15:17:53) ^-: [pjrm_home] Of course it could go into cvs as soon as 0.42 were released, though.
(15:17:56) egli: pjrm_home: you mean you applied the tag over the text buffer
(15:18:11) ^-: [pjrm_home] yes, over the [[GtkTextBuffer]].
(15:18:14) egli: ok
(15:18:43) egli: why would it introduce bugs, just because you add a tag to the text buffer
(15:20:26) ^-: [pjrm_home] the feature involves creating data structures to represent the different languages of different regions. Also creating [[GtkTextTag]]'s and doing stuff with [[GtkTextIter]] objects and [[GtkTextTagTable]] and a few other things.
(15:20:44) ^-: [pjrm_home] re the value of the feature: we have no gui to control xml:lang tags
(15:21:35) ^-: [pjrm_home] thus it has fairly small value, so there doesn't have to be much risk for the risk to outweigh the benefit.
(15:22:51) ^-: [pjrm_home] bryce suggests that we try to release fairly soon, in time for a certain conference.
(15:23:21) ^-: [pjrm_home] bbyak: your opinion?
(15:23:33) ^-: [bbyak] on what?
(15:24:13) ^-: [pjrm_home] whether it's worthwhile having the spell checker choose language by xml:lang tags if present, rather than solely on user's locale as the current cvs does.
(15:24:27) ^-: [pjrm_home] i mean, whether worthwhile doing this for 0.42
(15:24:56) ^-: [bbyak] i think it may be safe enough for 0.42, as this feature is not much used anyway
(15:25:06) ^-: [bbyak] afaik
(15:29:40) egli: well I wasn't thinking of applying different xml:langs to different regions. I was more thinking of just having one xml:lang per node. This would go a long way towards usable spell checking. I do not need different langs for different regions (at least not now)
(15:30:31) egli: if we just do that would it still be unsafe (as you do not need [[GtkTextIter]] if you only have one language per node)
(15:32:17) ^-: [pjrm_home] by regions, i just meant "regions of the text", as marked by e.g. <tspan> elements (or whatever other element, the code wouldn't care what element had the xml:lang tags)
(15:32:32) ^-: [pjrm_home] what do you mean by node?
(15:33:08) ^-: [pjrm_home] anyway, i'll see what I can come up with in the next hour or so.
(15:35:44) egli: I might not have the correct terminology. I call the xml:text element in XML a "node". From what I understand this corresponds to the element that I get when I insert a text object in inkscape
(15:38:46) ^-: [pjrm_home] egli: correct terminology, but a <text> element [i take it you mean svg:text, btw] can contain children like <tspan>, and the text that gets put in the dialog box could include many different tspan elements' text.
(15:38:55) egli: so I would attach the xml:lang attribute to the svg:text element as opposed to the svg:tspan
(15:40:03) egli: [yes I mean svg:text]
(15:42:13) egli: so you would want to allow for each tspan to have a separate xml:lang attribute. This would of course complicate things. It would also make the UI to enter the xml:lang attribute much more complicated. I would suggest to ignore xml:lang attributes on the tspan elements and only worry about xml:lang attributes of the svg:text element
(15:43:46) egli: From a users point of view I can live with a few "misspelled" words if I have a few english words in my german document.
(15:45:00) egli: However it would take me a long way if I could say this text is in english and that text is in german and have them spell checked properly. Say I'd have a bilingual flyer with german text on the left and english text on the right
(15:45:05) ^-: [pjrm_home] re ui, it should be the same complication as setting bold attribute.
(15:46:52) egli: pjrm_home: from what I can tell you can only set the bold on the svg:text node (at least in 0.41)
(15:48:13) ^-: [bbyak] not so in 0.42
(15:48:26) ^-: [bbyak] there's full support for styling text fragments now
(15:53:48) ^-: [pjrm_home] the documentation for gtk_text_buffer_get_iter_at_offset claims that its offset is number of characters, but that seems unlikely to me: i'd have expected number of bytes. Anyone know?
(16:57:51) ^-: [pjrm_home] oh dear. My previous test indicating that language [[GtkTextTag]]'s are respected, was faulty: apparently gtkspell is buggy in how it queries locale variables: [[LC_ALL]]=C doesn't override [[LC_MESSAGES]] for gtkspell.
(16:58:23) egli: uh, are you sure?
(16:58:40) ^-: [pjrm_home] So i incorrectly concluded that gtkspell got french from the [[GtkTextTag]], whereas in fact it got it from my [[LC_MESSAGES]] environment variable (which I thought was being ignored given I had [[LC_ALL]]=C).
(17:01:56) ^-: [pjrm_home] I'm quite disappointed about that: having implemented xml:lang querying fairly quickly, only to find that gtkspell is ignoring my work :-( .
(17:02:07) ^-: [pjrm_home] I should submit a bug report against gtkspell.
(17:02:41) ^-: [pjrm_home] it seems reasonable for it to get language info from language [[GtkTextTag]]'s in preference to querying locale.
(17:03:53) egli: hm, I was looking forward to spell checking :-/
(17:04:15) ^-: [pjrm_home] Especially when it seems that its locale querying is wrong anyway (or at least different from gettext's behaviour)
(17:07:26) ^-: [pjrm_home] Hey, I can trigger a crash by setting [[LC_MESSAGES]] to fr_FR.UTF-8 (or whatever other non-english UTF-8 locale) while having unset [[LC_CTYPE]].
(17:08:04) ^-: [pjrm_home] seems to be throwing an exception from Glib::locale_from_utf8
(17:08:41) ^-: [pjrm_home] [[SkoZombie]]: I usually have [[LC_MESSAGES]] set to french to help me learn french.
(17:15:09) ^-: [pjrm_home] oh well, bed time now. Night all.
(17:15:34) sciboy: Good night =)
(17:16:02) ^-: * pjrm_home has left: Déconnecté

irc log of user interface for language selection discussion:

(09:04:56) egli: pjrm: I was wondering what happened to your spell check work. Did you get up the next day and have a brilliant idea what the problem with [[GtkText]] and [[GtkSpell]] could be?
(09:05:44) egli: as this code is probably not going into cvs right now it might make sense to post it somewhere for people (like me :-) to look at and play with it
(09:11:05) pjrm: egli: I can send you the diffs, but it's only to apply language [[GtkTextTag]]'s to the text buffer. gktspell apparently doesn't honour those.
(09:11:52) egli: pjrm: yes, I'd love to have the diffs. That'll let me play with it and do some more experimenting
(09:12:00) pjrm: It might still be a good patch to apply anyway just to help pango and maybe screen readers (?), but the benefit for gtkspell will have to wait until gtkspell honours them.
(09:12:27) pjrm: i'll be home in half an hour.
(09:12:30) egli: I just cannot believe that gtkspell would have such a blatant bug
(09:12:31) pjrm left the room (Déconnecté).
(09:12:38) egli: it's used everywhere
(09:26:35) pjrm_home [pmoulder@bowman.csse.monash.edu.au/Gaim] entered the room.
(09:28:55) pjrm_home: presumably they just didn't expect to find language tags.
(09:29:23) pjrm_home: e.g. the buffer i'm typing in in gaim wouldn't have language tags.
(09:30:56) egli: "they didn't expect to find language tags"? Hm, the people behind [[GtkSpell]] are pretty smart, but then again nobody is perfect
(09:31:22) egli: have to look into this and do some debugging
(09:36:24) pjrm_home: Re putting something like the current patch into CVS: I hope to be able to extend it a bit such that e.g. bold sections get preserved when the user clicks Apply.
(09:37:05) egli: ah that would be good too. Then I could work from CVS
(09:38:12) pjrm_home: In current CVS, if you have some bits of the text with a different style (bold or whatever), then we don't keep track of that in the text edit box in Text & Font dialog, so clicking Apply will in effect discard markup.
(09:38:46) pjrm_home: (Not too much of a bug given that ppl rarely use that Text tab, but would still be nice to do right.)
(09:38:59) egli: uhh, I didn't notice that when playing around with it
(09:39:54) egli: then again if we accept this limitation we could also go for the limitation that language settings can only be set per [[GtkText]] and not individual regions
(09:39:57) pjrm_home: More controversially, we could attempt to translate inkscape style into [[GtkTextTag]] style. Not too controversial for just the odd bold/italic word or two, but more questionable for font size or font face.
(09:40:13) egli: from a user pov I think this is perfectly fine
(09:40:37) pjrm_home: yes, that would be a good start.
(09:41:07) egli: it would go a long way usability wise as I think it would cover the most common usecases
(09:41:14) pjrm_home: yep
(09:41:44) egli: I can accept that it would claim the odd misspelled word if I have one english word in a german text
(09:42:56) egli: also from the ui pov it would be much simpler: just specify one language in the "Text and Font" dialog as opposed to be able to specify a language for each region
(09:43:51) egli: how would the ui for changing the language of a selection in the text look like anyway?
(09:44:43) egli: I can only think of how it is done in OO.o 1.1.x. Pretty unintuitive somewhere under the character format settings
(09:50:09) pjrm_home: I'm not a user interface person. I was thinking of a text field and tickbox on the Text & Font dialog box, where the field greys out when the checkbox isn't ticked. I think there's a combo widget that allows selecting from a menu as a way of filling in the text box.
(09:50:35) pjrm_home: The checkbox is to distinguish between inherit or not.
(09:51:24) pjrm_home: The text field is because the set of allowable languages is infinite. (Also more convenient than selecting from a menu, once you know the format.)
(09:52:29) egli: I was thinking of just allowing for a combo widget which lets you specify a language or leave it at the default which would say "use document default"
(09:52:48) egli: would it make sense to be able to enter the language manually?
(09:53:09) pjrm_home: what do you mean manually?
(09:53:17) pjrm_home: do you mean type as distinct from select from menu?
(09:53:22) egli: I think the user should only be able to enter the languages for which she has spelling dictionaries installed
(09:53:37) pjrm_home: it isn't just for spelling on the local machine
(09:53:55) pjrm_home: e.g. it facilitates google searches
(09:54:03) egli: by manually I mean enter free form text in a text field as opposed to choose a selection from a combo widget
(09:54:24) pjrm_home: certainly it should be possible to enter free-form text.
(09:54:40) egli: hm I don't understand that
(09:54:56) egli: I just want to say that this text is in german
(09:54:57) pjrm_home: I thought combo widget meant something that allows either free-form text or selecting from a menu
(09:55:14) pjrm_home: then enter either de or de_DE or de_CH or select from a menu
(09:55:36) egli: ah, again my terminology, I mean a widget where you can only select from predefined vaules
(09:56:08) pjrm_home: let's call that a popup menu. (Can someone here who does more gtk stuff fill us in on the standard gtk terms?)
(09:56:23) egli: ok, sorry for the mixup
(09:56:49) egli: evolution let's you choose the language in the composer
(09:57:27) egli: and it uses user understandeable terms such as English (British) etc
(09:58:17) egli: but what was the story with google searches. Why would you want that in the Text and font dialog?
(09:58:54) pjrm_home: egli: It's good to have a menu available so that one doesn't need to know the right format, but it's also good to have text entry to allow less common languages, and because it's more convenient than selecting from a huge menu.
(10:00:26) egli: ok, I see, but presumably the user only wants to see the languages for which she has spelling dicts, doesn't she?
(10:01:31) egli: grandma tilly might be confused by a text box where she has to enter de_CH :-)
(10:01:34) pjrm_home: languages with spelling dicts available could be at the top of the list for convenience, though sometimes one wants to specify the language correctly even when one doesn't have the appropriate spelling dictionary installed at present on the current machine
(10:01:42) pjrm_home: grandma tilly can use the menu
(10:01:47) egli: hehe
(10:02:42) egli: I guess you do want to specify languages for which you don't have a dict, but that seems like a rare case
(10:03:01) egli: very rare
(10:03:56) pjrm_home: providing that possibility is i think one of the criteria for accessibility standards... I'll have a look.
(10:05:03) egli: maybe a question for the GNOME HIG people?
(10:06:51) pjrm_home: re google: google provides the ability to show pages/images for a specified language, e.g. searching for prix only in english pages to avoid the common french word meaning price.
(10:07:12) pjrm_home: e.g. searching for SVG images containing the word Grand Prix.
(10:10:10) egli: ah, now I get it. As you attach the xml:lang tag it can help with google searches. Yes. I thought you want to initiate google searches from the inkscape Text and Font dialog :-)
(10:10:43) pjrm_home: re "rare case", providing the ability to specify the correct natural language is actually a requirement for inkscape to claim to be a conforming svg authoring tool!
(10:10:48) pjrm_home: http://www.w3.org/TR/WAI-WEBCONTENT/#gl-abbreviated-and-foreign
(10:11:32) pjrm_home: i'll need to check that, but it's certainly a priority one item for creating accessible documents.
(10:12:42) pjrm_home: http://www.w3.org/TR/SVG11/access.html explains some of the relationship between svg conformance and accessibility
(10:14:55) egli: ok, you have a point there :-). It just seems against the "just works" principle. Too many options, too much confusion
(10:15:38) pjrm_home: I think guideline 1.1 and 1.2 at http://www.w3.org/TR/ATAG10/#gl-access-support indicate that this feature is a priority one guideline for authoring tools.
(10:15:53) egli: maybe a possibility would be to cover the grandma tilly case with a popup menu and let the specialists enter any xml:lang with the xml editor
(10:17:58) egli: I'm not saying we shouldn't let the user enter any language. I'm just arguing for an easy and intuitive way for the common case. Basically make easy things easy and hard things possible
(10:17:59) pjrm_home: grandma tilly might be a bit of an extreme case, for whom it would be beneficial to hide options. I for one would appreciate the convenience of having a text field as an alternative.
(10:18:21) pjrm_home: i think providing the menu is enough to make things easy & intuitive.
(10:18:34) egli: ah, yes, but you're not grandma tilly
(10:18:42) pjrm_home: granted
(10:18:52) egli: I guess I could live with the menu :-)
(10:19:26) egli: grandma tilly won't notice that she could also enter text there
(10:20:44) pjrm_home: for grandma tilly, i believe it would be an improvement to suppress the text field. But for Andy Artist I'm not so sure; i'm inclined to think Andy would like the text field to be present so long as it doesn't cost too much space on the dialog box.
(10:21:08) pjrm_home: Having an Other... entry in the menu is another approach
(10:21:22) pjrm_home: that approach doesn't provide the convenience benefit though
(10:22:02) egli: andy the artist could edit the in xml editor
(10:22:27) egli: let me see how gimp handles this
(10:23:16) pjrm_home: most of gimp's output formats don't represent text as text, so the ability to specify language isn't very relevant other than for spell checking
(10:24:13) egli: ok, fair enough
(10:24:50) egli: looks like you cannot even do spell checking in gimp 2.2.4
(10:26:32) egli: I'll try to talk to my A Illustrator friend to find out how it is done there.
(10:34:28) pjrm_home: also valuable is guessing the language automatically. http://odur.let.rug.nl/~vannoord/TextCat/competitors.html has a few tools for this. Checking in available spell checkers is an alternative.
(10:36:46) egli: hah, now we're getting fancy. I'd go for the easy stuff first, e.g. just use available spell checkers. language recognition can always be added :-)

Coding Style

2012-12-28T20:16:23Z

Romain2Boss: Link fixed

== Inkscape Coding Style Discussion ==

The official code style documentation is on the main website.
"http://www.inkscape.org/doc/coding_style.php"

This page is for discussing and working out changes and improvements to that document. When concensus
is reached, the document can be updated in SVN in the inkscape_web module.

=== Editor support ===

Place the following at the end of source files to help emacsen & vim users follow some of our guidelines automatically:
<pre>
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 :
</pre>

Once you've added those lines, close the file and re-open it for it to take effect.

Then (for emacsen users), one can re-indent a region with C-M-\.

=== camelCase v. Underscores ===
* The new coding standards require non-static member functions to be in pseudoCamelCase, and every other type of function to use underscores.
* The current codebase has very few real C++ objects, half of these objects (or more) seem to use underscores for their member functions, the other half seem to use pseudoCamelCase.
** Over-all, 95% of Inkscape's codebase uses underscores in function names (of course, 90% of the code is still C).
*** It seems underscores are what Inkscape developers are already used to.

* I prefer CamelCase for type names (classes), exceptions, namespaces, and the like. But pseudoCamelCase in member functions clutters the visual space; making types, exceptions, and namescapes stand out much less. And it makes the code much harder (for me) to read.

** This is a personal preference. I find CamelCase to be more legible and more concise, as it takes less space and thus allows for longer identifiers. [[User:JonCruz|JonCruz]]

** Why is there this inconsistency with regard to function names in the new coding standard?
*** (I.e., why a few functions pseudoCamelCase, and everything else underscores?)
** Could all functions just use underscores? (Like the current codebase, like Gtkmm, like Linux, like the C & C++ standard libraries, and like almost every other project out there?)
** Is static vs. non-static member functions really that big of an issue to warrant a change to pseudoCamelCase?

* Hey, we're not programming in Java (or Qt) here! This is C++, where underscore reigns supreme.

** A key point here is the misconception that camel case is not a C/C++ thing. Many platforms used camel case, including the Microsoft Windows API, Apple Macintosh API, etc. [[User:JonCruz|JonCruz]]

** CamelCase is also prevalent in many other "non-pc" languages such as Smalltalk.

=== Underscore as first character of identifiers ===
* Please consider that the C++ standard reserves _* identifiers [17.4.3.1.2]: "Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace".
* You can use a '''leading underscore for class members''' (variables of a class), to clearly mark them as a class member. This may prevent bugs: for example a temporary variable called 'curve' would hide an SPShape's '_curve' member if it did not have that leading underscore.

=== Tabs and Alignment ===

Inkscape code uses 4 spaces for indentation and '''no tabs anywhere'''.

That's clear (not to mention sensible). However, on the mail Coding Style page it says this:

We have decided to use 4 spaces as a tab for the project.

Calling it a "tab" (rather than something like "indentation amount") is a little confusing, I think. It made me think that source files should have tab characters, but that the editor should be set up to interpret them as being 4 columns (i.e., taking you to the next multiple of 4 columns).

=== Whitespace: Space between sigil and following token? ===

I.e. do we write ‘<code>int *p</code>’ or ‘<code>int * p</code>’; ‘<code>int *f()</code>’ or ‘<code>int * f()</code>’; ‘<code>int *const p</code>’ or ‘<code>int * const p</code>’ ?

Arguments in favour of no space:

* Promotes better understanding of C/C++'s parsing rules for cases like ‘<code>int *a, b</code>’: the sigil applies only to <code>a</code> in that example, not to <code>b</code>.
** This argument is much less applicable to the case that the following identifier names a function: it is very rare for function prototypes to “syntactically share return types” that way; this rarity reduces the importance of knowing the meaning of ‘<code>int * a(), b()</code>’.
* Less horizontal whitespace usage (reducing the chance of overflowing the available width or requiring a continuation line).
** However, note that overflow is rare for variable declarations; for function headers, continuation doesn't hinder understanding of the header in question, so the argument rather becomes one of taking up more lines, reducing how many statements are visible in one screenful.
* For the case of declarations inside function bodies (and other cases as well, to a lesser extent), ‘<code>Foo * foo</code>’ is more easily mistaken for executable code (as distinct from a declaration) than ‘<code>Foo *foo</code>’ is.
* Less typing. (Minimal importance.)

Arguments in favour of space:

* For the cases where the following token is an identifier, improves the legibility of the identifier. For cases where the following token is a cv-qualifier (‘const’, ‘volatile’), the space improves the legibility of the sigil.

An additional issue is the relative prevalence of the approaches in existing code: this relates to either consistency or the cost of changing code (to the extent that changing is done manually).

Before doing any counting, the impression of one developer [writing this] is that no-space is much more common, but with-space is far from unheard-of. (It's valuable to get an informal impression as a defense against any deficiencies in simplistic automated counting: e.g. we ought to give more weight to code that's often looked at / changed than code that's less often looked at or changed, and should give more weight to code considered Inkscape code than imported code.)

The results of a simplistic automated count confirm that: there are 28037 lines with the no-space style to 7204 lines with the with-space style, a ratio of about 3.9:1; or 1899 vs 746 (2.5:1) in .h files. For the following-token-is-function-identifier case, the gap is narrower, at 1350 vs 792 (1.7:1).

The simplistic automated count in question is:

:find $ -name '*.h' -o -name '*.cpp' $ -type f -print0 |
::xargs -0 cat |tr '\t' ' ' |
::egrep -c '(void|int|unsigned|char|short|float|double|\<[A-Z][a-zA-Z0-9_]*)(( *const)? *[*&])+[a-zA-Z_]'

for no-space, and inserting ‘ +’ before the final ‘[a-zA-Z_]’ for with-space. (‘volatile’ is not used in Inkscape source code at the time of writing.) For the following-token-is-function-identifier case, the final ‘[a-zA-Z_]’ was extended to ‘[a-zA-Z_][a-zA-Z0-9_]* *\(’. Note that this means that both the no-space and with-space counts exclude Gnu-style function definition heads (where the return type is on a separate line).

=== Brace Placement ===

Arguments against "disco"/compact braces:

* Make it hard to match braces visually.

:Partial counter-argument: emacsen & vim each have brace-locating commands. (Emacsen: C-M-u, C-M-n, C-M-p, C-M-d (up/next/prev/down); vim: `[ {', `] }'.)

* The brace closes a block, not an if "statement".

:However, the block is intimately related to the if/for/while in ways that a normal block is not.

=== Functions vs methods, i.e. member vs non-member functions ===

* Information-hiding principle suggests that if a function doesn't need access to private variables then it's better not to make it a member function.

** In more detail: when one wants to change some detain about a private variable, then one must look through everything that has access to that variable. This is easier if there's less code that has access to the variable, e.g. if one uses non-member functions in preference to member-functions.

* Virtual functions must of course be member functions.

* Trivial getter/setter functions seem most natural as member functions. (This is mostly a matter of style or tradition rather than technical reasons.)
** "barType getBar() const { return _bar; }" / "void setBar(barType x) { _bar = x; }" are trivial. It's not clear how much else is to be considered trivial.

* For things needing access to private variables, the requirement of the `friend' declaration for non-member functions is a cost: extra clutter in the class definition, requires updating for changes in the signature; and many of the arguments for non-member functions disappear.

* Member functions must be declared in the class definition, which tends to require more recompilation because one can't use a separate header file.

** Sometimes one can break the class into smaller, simpler classes if there are lots of member functions.

* A related issue is that it's harder (impossible) to write private specializations (same name but subclass arguments): any specialization must be declared in the class definition too, so it isn't private other than through comments.

* The shorter names typical of member functions are harder to search for.

** (Counter-argument: this is a matter of custom, there's no technical reason why one can't use long names for member functions, or even short names for non-member functions.)

** Someone has claimed that some tools do relatively well at finding the right version of a given name. Can someone give examples of such a tool (and some comment as to how widely used that tool is or can be by our developers) ?

* Pointers to member functions aren't as easily used as pointers to non-member functions. ("unwieldy", "heavy-weight".)

* Member functions can't be given static linkage.

=== <tt>static</tt> vs anonymous namespaces for file-local functions/objects ===

The current C++ standard marks this type of `<tt>static</tt>' as deprecated, meaning "Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions".

(Reference: Final Draft of the C++ standard, Annex D "Compatibility features"; and §7.3.1.1 "Unnamed namespaces", ¶2.)

However, g++ up to 3.4 (and possibly later) don't give anonymous-namespace names the same advantages given to static names:

* Warning if the name isn't referenced (and hence unused).
* Optimizations when the function/object can't be used from other object files.
* Static linkage (relevant to analysis using nm).

In addition, having a <tt>static</tt> tag in the declaration itself makes it easier for the programmer to see that the name isn't referenced outside of this translation unit.

Consequently, it is recommended that we use <tt>static</tt> for names not referenced from other translation units.

If and when we encounter a compiler that rejects `static' for objects in namespace scope, we can easily replace `<tt>static</tt>' with `<tt>namespace {</tt> ... <tt>}</tt>'.

=== What to put in what header file ===

Reasons for change:
* Reduce compilation times (most important)
* Fix the mess of NR::Point, NR::Matrix etc. header files. Less confusion as to what needs to be #included, or where to look for the definition of something (especially in the cases where tags-like programs don't help, e.g. if looking for something helpful for a known task rather than having a known name).

What won't change:
* foo.h will still provide the same things it always has (unless you count things "accidentally" provided, which we hope to become less). It's just that some content may be physically moved to a file that foo.h #includes.

The issues are:

* Ease for callers (what file/s to #include). This is largely taken care of by having files that #include other header files, and in particular having the foo.h file as at present.

* "I need to change the blah declaration/definition; what file do I edit?".

* Information we want ppl to be aware of.

Definitions are handled by tags/idutils/global etc (though all of these tools have limitations in their ability to find the _right_ definition).
Declarations that are separate from the definition: [non-member] function declarations are the main case. member functions (obviously kept in same physical file as their class definition); non-member functions

Here are some types of things to be found in header files. Whatever rules you hypothesize, check that the rules cover each of these cases.

* class foo definition
* "class foo;" forward declarations
* struct foo_class (i.e. GObject "class"/vtable type)
* IS_FOO, FOO cast etc. macros
* ancilliary types (e.g. struct StopOnTrue for marshalling)
* enums
* relevant instantiations (traits etc.)
* foo_do_blah (declaration of function defined in .cpp file)
* inline function definitions
* should declaration & definition of inline functions go in different files (there are pros & cons)
* other constants, including #defines
* other macros. Where is the line between "other macro" and "inline function" and IS_FOO macros?

The physical placement of the IS_FOO etc. macros (as distinct from what header files "provide" them) isn't important: we never need to edit them, and they're relatively easy to find by either primitive tags-like programs or by grep.
* This unimportance-of-physical-location is reflected in the inconsistency of current practice, sometimes placing them with foo.h and sometimes in blah-forward.h.
* Exception to unimportance-of-physical-location: IS_FOO etc. should not be physically in the same header file as something that's "expensive" and unneeded by one or more translation units that need IS_FOO etc. ("Expensive" in same sense as `amount' defined below in `Reducing compile times'.)

The main thing for IS_FOO etc. is what header file(s) provide the macro. Thankfully, this is easy in the common case: usually any function that needs the definition of IS_FOO also needs lots of other things relevant to the foo type, so would simply #include foo.h.

Relevant properties of function declarations:

* It is common to add or remove functions, or change the arguments.

* Typically not found by tags-like programs. E.g. neither `tags' nor `TAGS' files store the location of declarations (other than the definition).

* Programmers want to know what functions (including methods, macros, inline things) are available (or rather "is there something that does blah").

** Probably doxygen or the like is the best task for this, though we'd need to make it convenient to use.

* Needed in advance of function definitions (whether in .cpp file or inline function definitions). Not needed in advance by macro definitions per se (but needed in advance of function definitions where the macro is expanded).

Inline function definitions:

* Relatively expensive in compile time for translation units that don't use that inline function definition.
* Must come after (in the translation unit) all referenced declarations. Sometimes this requires that it be outside of the class definition or in a separate file from related declarations. (E.g. if foo.h and bar.h each provide an inline function definition that requires declarations provided by the other file.)

Operator overloading:

* Can be unclear whether to associate with the type of the left operand or the type of the right operand.
* We can simplify things for users of the function by having both left.h and right.h provide it (i.e. have both left.h and right.h #include it). This suggests that it should be physically neither in left.h nor right.h (unless it's OK for left.h to pull in all of right.h or vice versa).

Reducing compile times

* For each translation unit U, reduce the amount of material that gets included by U and isn't needed by U.
** "Amount" is measured by cost: how often that material changes (causing a recompile), and how expensive it is to compile (e.g. inline function definitions).

* In what circumstances does a translation unit include things that it doesn't need?
** Inline function definitions.
** Needs a function declaration but doesn't need the type definition.
*** A special [non-] case of this is needing a member function declaration. Member function declarations can't be separated from their class definition. See also `methods vs functions' above.
** Suppose that struct Foo has a `Bar _bar' member. The translation unit may need to create Foo objects (and thus need the type definition of Bar to know its size), but not need to access _bar (so not needing anything from bar.h other than the type definition of Bar).
*** This is very common. Common examples of Bar: SPShape, NR::Point/NR::Matrix.
** Needs some function declarations but not others.
** Needs some type forward declarations but not others.
** Comments are never needed for compilation.
** Definition of a marshaller is needed only by emitters. However, it's difficult to separate the marshaller from the signal, and difficult to separate the signal from the definition of the containing type (SPDesktop, SPItem).
** Including the definition of a type when its declaration would suffice.
** Copy&paste of #include lines.

* Ways of reducing the need for type definitions:
** Store just a pointer instead of the whole type.
** Provide a wrapper function (not inlined) for `new Foo'.

==Preprocessor MACROS==

Capitalizing or not?

# define IS_FINITE(_a) (std::isfinite(_a))

===Arguments pro capitalizing===
* Macros don't have a namespace and can therefore easily clash with other names. This happened in the isFinite case. where we had across several files:
#define isFinite(x) ...
...
class Point {
bool isFinite(int x)
}
This obviously nameclashed, where a capitalized IS_FINITE would have never clashes as (I guess) nobody uses capitalized function names. Note that an inline function instead of macro would also have worked.
* Some macros can expand strangely (don't have good example now), so it is good that the user knows it does so.
* Note that it is often also possible to define an inline function instead of a macro!!! (which is a better solution?)

===Arguments against capitalizing===

== User Interface Coding Rules ==

=== Complex User Interface Items and Containers (Dialogs, Panels, Frames...) ===

* Each one have to be developped as a C++ class
* Declare all UI widgets that are used in the container as protected initialisation-time allocated members
protected:
Gtk::Label _anchorLabel;
* Initialize all widgets in the member initialization list of the container constructor
MyDialog::MyDialog():
_anchorLabel(_("Look at this label"))
{
...

=== Dialogs ===

* Dialogs source codes have to be localized in src/ui/dialog/
* A dialog belongs to the namespace Inkscape::UI::Dialog

=== Widgets ===

* Widget source codes have to be localized in src/ui/widget/
* A widget belongs to the namespace Inkscape::UI::Widget

[[Category:Developer Discussion]]

PDF Bugs

2012-12-28T20:14:41Z

Romain2Boss: Link fixed

== Bugs ==

* Bug#1027699 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1027699&group_id=93438&atid=604306 imported EPS files are scaled to 80%]
* Bug#1051080 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1051080&group_id=93438&atid=604306 ill2svg missing text]
* Bug#1114254 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1114254&group_id=93438&atid=604306 cannot open/import eps files]
* Bug#1170322 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1170322&group_id=93438&atid=604306 Clippath does not work in PS export]
* Bug#1180226 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1180226&group_id=93438&atid=604306 Can't open .eps file.]
* Bug#1208874 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1208874&group_id=93438&atid=604306 pattern fills do not export to ps or eps]
* Bug#1222689 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1222689&group_id=93438&atid=604306 EPS export of non-ASCII text]
* Bug#1234678 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1234678&group_id=93438&atid=604306 PNG transparency lost after EPS->PDF export]
* Bug#1237867 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1237867&group_id=93438&atid=604306 EPS export options issues]
* Bug#1239993 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1239993&group_id=93438&atid=604306 Importing problems in 0.42 pre2 on OSX]
* Bug#1246558 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1246558&group_id=93438&atid=604306 windows -export-text-to-path do not work]
* Bug#1247093 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1247093&group_id=93438&atid=604306 Export to PDF does not preserve the document size]
* Bug#1267081 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1267081&group_id=93438&atid=604306 imported images: no relative paths/wrong absolute path]
* Bug#1273753 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1273753&group_id=93438&atid=604306 Exporting EPS creates a too-wide picture]
* Bug#1275197 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1275197&group_id=93438&atid=604306 Hyphen too long in Postscript output]
* Bug#1302072 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1302072&group_id=93438&atid=604306 ill2svg imports incorrectly]
* Bug#1305178 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1305178&group_id=93438&atid=604306 export to eps problem with symbol and xrefs]
* Bug#1311015 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1311015&group_id=93438&atid=604306 Win32: stroke dashes disappear in eps files]
* Bug#1333035 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1333035&group_id=93438&atid=604306 EPS import: text items are corrupted]
* Bug#1373339 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1373339&group_id=93438&atid=604306 PS/EPS/PDF export wrong font name]
* Bug#1378123 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1378123&group_id=93438&atid=604306 EPS export: [[BoundingBox]] crops image (rounding issue?)]

== RFEs ==

* Rfe#864260 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=864260&group_id=93438&atid=604309 IMPORT/EXPORT: PDF]
* Rfe#957916 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=957916&group_id=93438&atid=604309 Import/Export Encapsulated [[PostScript]] format]
* Rfe#989220 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=989220&group_id=93438&atid=604309 How can i export to illustrator? Copy/paste inkscape/flashmx]
* Rfe#1055693 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1055693&group_id=93438&atid=604309 import, PS files drawing text using pstoedit]
* Rfe#1197549 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1197549&group_id=93438&atid=604309 Native PDF import for Inkscape, using Poppler]
* Rfe#1280894 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1280894&group_id=93438&atid=604309 Image Transparency Portion in PS/EPS]
* Rfe#1304728 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1304728&group_id=93438&atid=604309 More import and export formats needed (.eps,.fh9,.ai)]
* Rfe#1341467 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1341467&group_id=93438&atid=604309 Print vector graphics on pdf "software" printer]
* Rfe#1373349 -- [http://sourceforge.net/tracker/index.php?func=detail&aid=1373349&group_id=93438&atid=604309 Option: Print to PDF]

[[Category:Needs Work]]

NewTools

2012-12-28T20:12:35Z

Romain2Boss: Link fixed

=== [http://sourceforge.net/tracker/index.php?func=detail&aid=880120&group_id=93438&atid=604309 Cloud Tool] ===

Any selected object or group of objects will have generated a "cloud" or
outline. Variables could include but not be limited to: distance between
original object and cloud, number of clouds, distance between original object
and each succeeding cloud, and so on.

=== [http://sourceforge.net/tracker/index.php?func=detail&aid=880099&group_id=93438&atid=604309 Razor Tool] ===

Any selected object or group of objects could be split along the line drawn by
the "razor" tool. This is essentially a combo of adding a node, breaking a line
at the node, inserting a line, and joining the resultant nodes.
Almost the same as scissor tool, but indeed very handy!

=== [http://sourceforge.net/tracker/index.php?func=detail&aid=880110&group_id=93438&atid=604309 Add/Subtract Nodes + Scissor Tool] ===

==== ADD NODES ====

Similar to most vector editing apps, we need a tool to
be able to click on a shape, and then add a new node
wherever the ADD tool clicks on a segment. This add
tool should be the node edit tool with a plus icon
located at the bottom right corner of the icon.

==== SUBTRACT NODES ====

Also we need a tool so that when one clicks on a point,
then that point is removed. I guess we already have it
so when a point is selected, one can hit the delete key
and that point is deleted and the shape remains. I
don't know how intuitive this is, and think there
should also be the node edit tool with a small minus
symbol on the icon that will do the same thing.

==== SCISSOR TOOL ====

Related to the ADD/SUBTRACT Nodes is to select the
scissor tool from the node edit toolbar or primary
toolbar and be able to click anywhere on a shape's
segment and break the segment into two pieces where
this tool clicks on the line.

==== SCALE, ROTATE TRANSFORMATION TOOL FOR MULTIPLE OBJECT PATH NODES OR POINTS ====

Currently If you are in path node editing mode and selected more than one node, you cannot rotate or scale them (Only moving).
In vector world not everything done by simple moves. If you look at other tools you would see that this is a well implemented feature
in professional tools.

==== INTERACTIVE PERSPECTIVE AND DEFORMATION TOOLS====

I do not think we need to go into detail of why we would need interactive deformation tools :) They are very curicial elements for
vector logo-amblem design, illustration, pattern creation and layout designs etc.

==== FLASH-LIKE PAINT TOOL ====
The user draws a 1-bit raster image with the mouse or stylus, when the mouse button is released, or the stylus is lifted, the raster image is vectorised (like the paintbucket tool) resulting in a slightly irregular 'painted' shape as opposed to the more uniform, neat look of the calligraphy tool. The technique automatically insures that there are no internal lines and the self intersections of the brush stroke are smooth.

=== SHARD EDGED DYNAMIC/LINKED OFFSET ===
Right now Dynamic and linked offset always offset with a rounded edge. A mode that allows the sharp edges to be kept sharp would be useful.

=== [https://sourceforge.net/tracker/index.php?func=detail&aid=908792&group_id=93438&atid=604309 Cloning/Spraypaint of Objects Tool] ===

=== Variable Stroke Width Path===
this could be driven at each node, but a method for varying the stroke width along the path would be very useful.

=== [[Intersection Tools]] ===
These are more intuitive implementations of the "Cut Path" tool.
Makes some vector graphic operations very easy to do.

=== Dropbox ===
just storage area, when you put an object you don't want on your page but you don't want to delete.

CorelDraw

2012-12-28T20:08:44Z

Romain2Boss: Add Other Software Category

Please post links to screenshots and/or insights of this vector app. We must learn from others.

[http://www.ex-astris-scientia.org/misc/software_test.htm Comparison] (from the point of view of technical drawing) of Corel Draw 9, iGrafx Designer and Adobe Illustrator 8. Fairly detailed. The comparison criteria paragraphs are also interesting in showing the features that the writer finds useful.

Corel also provides Comparisions to other products on their website. It does give an interesting idea of what they consider their own strengths and selling points to be (but you have to be very sceptical and take it with a fistfull of salt).

=== Screenshots ===

[http://en.wikipedia.org/wiki/Image:CorelDRAW.png Screenshot of [[CorelDraw]]] at Wikipedia.

Please add more ...

=== Corel Draw Plug-ins ===

[http://www.painterscase.com/plugins/corelplugs1.html Plug-ins for Corel Draw ]

=== Links ===

[http://www.coreldraw.com/ Official Corel Draw web site]

[http://en.wikipedia.org/wiki/CorelDraw Corel Draw page at Wikipedia]

[[Category:Developer Discussion]]
[[Category:Other Software]]

Xara X

2012-12-28T20:07:37Z

Romain2Boss: Add Other Software Category

= Features in Common =
*In brief: both are multi-platform and are protected by the GPL. Inkscape is free software; so is part of [http://xaraxtreme.org/ Xara Xtreme] 3 (the renderer part of Xara is still closed and binary-only) but not 4.

= Inkscape Advantages =

=== Fundamental ===
* completely free and open source (Xara Ltd. refuses to open-source its renderer library)
* open, text-based, XML-based standardized format (the [http://www.xara.com/support/docs/webformat/spec/ Xar File Format] is a published standard too, but not XML, and not widely adopted)
* scriptable (rich command line)
* extendable (perl/python extensions)
* more localisations
* ports for OSX and other Unixes, apart from Windows and Linux; all ports have the same functionality (Xara's Linux port is stagnating, only Windows version is being developed)

=== Features ===
* smoother and more powerful bitmap tracer
* live XML tree editor
* gaussian blur (not the same as feathering; blurs everything, can be squeezed and rotated)
* other generic filters (turbulence, composite, displacement map, etc), ability to compose filter stacks
* live clones (copies that are linked to the original and update when it's changed)
* clone tiler (can be used for two-dimensional object scattering with randomization and coloring)
* tile tracing (tracing anything by a pattern of clones)
* unclumping (two-dimensional, incremental equidistant distribution of objects)
* randomizing object positions
* paint bucket tool to fill any bounded area with a path
* 3D box tool [not the same as Extrude that gives photorealistic rendering of individual objects; rather, this is a building block of coordinated 3D scenes]
* eraser tool
* tweak tool to push, inset, outset, roughen paths and to paint/jitter colors
* live path effects (pattern on path, sketch, various deformations, geometric constructions), stackable and applicable to groups
* Spiro splines (more convenient than Beziers)
* [http://www.openclipart.org/ Open Clip Art Library (OCAL)] integration [Xara can download stuff from its own site only]
* baseline snapping, alignment, distribution
* find dialog (find any object by type, style, id, etc)
* persistent per-object export hints (filename, resolution)
* export and conversions from command line, including batch export with GUI and commandline [Xara has batch export via GUI only, using Names gallery]
* command line query options to examine objects in a drawing
* command line access to verbs (commands) to automate tasks
* hierarchical layers, "enter group" command making it a temporary layer
* pattern fills from arbitrary objects; stock vector patterns
* gradients/patterns on stroke as well as fill
* gradient handles can be multiple-selected, selected by marquee, Alt+dragged to smoothly shape, copy/paste styled; gradient can be simplified to remove extra handles
* transform/not transform switch for patterns and gradients
* switch to preserve rounded rect corners in transforms
* scale/rotate/skew any number of objects separately, each around its own center
* numeric skew (both axes; by angle, %, displacement)
* editing transform matrix
* persistent per-object rotation centers
* pasting of size, width, height
* simplify-like deletion of nodes
* node sculpting
* symmetric nodes
* different star/polygon rounding (both Xara's and Inkscape's approaches have their advantages)
* randomized stars
* spirals
* easy segment and arc from ellipse
* the ability to combine color and transparency in a gradient
* linked offsets and text-on-path remain freely transformable
* convenient calligraphy pen (sensitive to tablet pressure/tilt, speed and direction, with tremor/wiggle)
* guided drawing, tracing background in calligraphic
* flowing text into arbitrary shapes, chaining, exclusion
* one-command removal of kerns from text
* rotating characters in text (including text on path)
* connector tool for diagrams
* automatic diagram layout
* removing overlaps
* extensions for paths: randomize, add nodes, swirl, fractal, function plotter and many others
* extensions for colors (inverse, more saturation, replace etc) and text (sentence case, randomize case, replace etc)
* extensions for rendering barcodes, function plotter, L-systems, and many others
* icon preview
* masks separate from fill
* vector import of PDF and CS AI (Xara either fails or imports by rasterization)
* autosave

=== convenience ===
* overall, '''times''' more keyboard shortcuts than in xara
* a large part of all keys are configurable (including Xara emulation option) via an XML config file
* keys for canvas scrolling (with acceleration)
* keys for scaling and rotating (including pixel-size)
* keys for scaling and rotating (including pixel-size) of nodes, including scale/rotate of node groups
* keys for letterspacing, linespacing, kerning in text (including pixel-size)
* nodes can be moved with snapping along the adjacent straight line segments or their Bezier controls
* more snapping options, on-canvas snapping indicator
* gradient handles can merge and unmerge
* history of zooms (Xara has a single "previous zoom")
* zooming by single key (+/-, without ctrl)
* any kind of zooming (including area) without tool switching
* "bounding box" per-object selection hints
* cursor changes over selectable objects
* node tool optionally highlights mouseovered paths
* more precision in editable numeric fields

= Xara advantages =

* fast renderer
* blends [Inkscape has limited path+style blending via Interpolate extension]
* envelopes, including curvilinear and perspective [Inkscape has non-interactive analog via Envelope and Perspective extensions; also non-perspective destructive distortions can be made via node sculpting or tweak tool]
* linked colors
* Pantone colors
* Photoshop plugins[[/Live]] effects
* integrated Picture Editor for embedded bitmaps
* brushes along path can be used for object scattering with randomization [Inkscape's pattern-along-path LPE has no randomization]
* variable stroke width, with selectable profiles or taken from pressure sensitivity [Inkscape can do this via pattern-along-path LPE]
* feathering objects' edges (not the same as blurring - only inward from edge, like a blurred transparency mask) [can be emulated in Inkscape via clone+blur+mask]
* more gradient types (conic, 4-point etc) [a limitation of the SVG specification, only linear and radial are defined]
* bevel tool (outer/inner; join types; size; light angle and elevation; flat/rounded/chiseled etc types (15 in total)) [some of this can be done in Inkscape via filters]
* "nav bar" tool for buttons (hidden in Xtreme)
* quick transparency gradients separate from fill [to some extent, can be emulated by SVG masks]
* gradient profiles [SVG limitation, in Inkscape can be approximated by multistage gradients]
* rainbow/alt-rainbow gradient options
* different star/polygon rounding (both Xara's and Inkscape's approaches have their advantages)
* some input and output formats that Inkscape does not support, including Flash; but not yet SVG
* non-AA display mode (note: anti-aliasing is _not_ a significant factor in the speed of Inkscape)
* linked stretching (autoscaling objects), e.g. stretching button to fit the text

==3.2 features:==
* Integrates with external photo editors
* MS Word copy/paste
* RTF, raw photo import
** RTF import can be done via GTK APIs. Raw photo import should use dcraw, or code derived from dcraw.
* PDF-X export
* XPS import/export
** This a royalty-free XML-based PDF replacement format from Microsoft. There is FOSS support for it, i.e. in Okular for KDE4.
* Multipage
* Text tool: paragraph spacing, snapping to pixel grid, soft hyphens, smart quotes
* PSD import/export
** Would require reverse-engineering Photoshop, as there is no published specification
* Flash animations
* Color separations
** This means producing copies of the original image, each one containing one of the channels. This should probably be postponed after the Cairo move.

==Version 4 features:==

* 3D extrude tool with 3D rotation and lighting controls
* HTML export with images
* text flow around shapes
* text underline
* optional Adobe-like rubberband selection - objects that are touched by rect
* live selecting while dragging
* fonts grouped into families in Font list
* key shortcuts customizable

= Per-feature comparison: =

== Rectangle tool: ==
Xara:
* Corner curves must be the same on each side of a corner, but then stretch if the object is resized. The curvature units aren't either percentages or pixels...?
* Can create with rotation ("Radius creation" and "Diameter creation" options)
* Can edit centre X/Y numerically
* Can convert to ellipse by doubleclicking center

Inkscape:
* Preview as-you-draw
* Corner radii only in absolute units
* A switch to preserve corner radii in scaling

== Rotation centers: ==
Xara:
* BAD: looks like once you move a center of an object, ALL objects will use the same center!
* BAD: does not survive save/reload - all objects are reset to geometric centers. (In other words, the center seems to be the property of the Selector tool, not of objects!)
* with Ctrl, center snaps to corners/midsides

Inkscape:
* Each object has its own center; if you want to rotate multiple objects around one center, just select them all (taking the object with the center first)
* Centers persist through save/reload
* Centers snap to edges and corners/midsides

== Bitmap tracer: ==
Xara:
* BAD: all parameters are set in some relative values in the range 1..100, except for "number of passes" which does not correspond to anything quantifiable. There's no way I could find to set explicitly the number of colors.
* BAD: as a result, tracing a simple line art such as a two-color logo is nearly impossible. Xara almost always creates a bunch of dirt at the fringes due to antialiasing, and shapes get distorted a lot. The Monochrome option seems to be broken.
* BAD: for photos, there's no stacking option, so full-color traces come out very untidy. The shapes are also more distorted than in Inkscape. If you try to make them less distorted, they start getting pixelated.

== Pen/shape editor tool: ==
Xara:
* with the pen tool you can drag curve and nodes (with snapping and closing) while the tool is active but, strangely, not node handles. with the shape editor tool the handles can be moved and new points also added
Inkscape:
* live preview of the next segment (exists in Xara when clicking/holding and dragging with the shape editor tool)
* you can create hor/vert straight line segments with Ctrl (the same in Xara but only with the shape editor tool)
* length/angle display in statusbar (again, in Xara only with the shape editor tool)
* you can easily create disconnected subpaths (starting with Shift)

== Path simplification: ==
Xara:
* slider for the just-drawn freehand line (only), to refit both ways (looser or tighter) while it's still selected
* interactive 0-100% slider in Node tool, looser only but remembers setting while you have the same nodes selected lets you de-simplify back
* works on selected nodes (actually, ONLY works on selected nodes)
Inkscape:
* Ctrl+L works in any tool, smoothing incrementally with acceleration
* has wider range and works more gradually
* works on multiple objects, and on whole object without node selection

= Screenshots =

[http://www.xara.com/products/xarax/screenshots.asp Screenshots on the Xara site] Page mirror: [http://web.archive.org/*/http://www.xara.com/products/xarax/screenshots.asp Web Archive]

[http://www.xara.com/products/xarax/screenshots/brushes.jpg Screenshot showing Xara Brushes]

[http://www.xara.com/products/xarax/screenshots/Gallery.jpg Screenshot showing Xara Clipart Gallery]

[http://www.xara.com/products/xarax/screenshots/55Chevy(outlines).jpg Screenshot of Xara depicting a Chevrolet Automobile]
[http://www.xara.com/products/xarax/screenshots/55Chevy(outlines).jpg Screenshot of Xara Wireframe View of Chevrolet Automobile]

= Links =

[http://www.xara.com/products/xarax/ official site]

[http://www.xaraxone.com/ community site of artists]

[http://xaraxtreme.org open source Xara Xtreme]

[http://www.xara.com/support/docs/webformat/spec/ Xar File Format]

[http://en.wikipedia.org/wiki/Xara_X Xara at Wikipedia]

[http://www.talkgraphics.com/showthread.php?t=26337 A relevant thread on Talkgraphics]

[http://www.talkgraphics.com/showthread.php?t=26742 Another relevant thread on Talkgraphics]

[http://www.talkgraphics.com/showthread.php?t=31719 Yet another relevant thread on Talkgraphics]

[[Category:Other Software]]

Customizing Inkscape

2012-12-28T15:47:55Z

Romain2Boss: /* Change keyboards shortcuts */ Add a list of predefined shortcuts files

== Change keyboards shortcuts ==

There is no user interface to customize shortcuts yet but you can edit ''<Inkscape install directory>share/keys/default.xml''.

In order to share same shortcuts than other softwares, following configuration files are shipped with Inkscape (look at the ''<Inkscape install directory>share/keys/'' folder):

* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/acd-canvas.xml acd-canvas.xml] for ACD System Canvas 11
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/adobe-illustrator-cs2.xml adobe-illustrator-cs2.xml] for Adobe Illustrator CS2
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/corel-draw-x4 corel-draw-x4] for Corel Draw X4
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/macromedia-freehand-mx.xml macromedia-freehand-mx.xml] for Macromedia Freehand MX
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/xara.xml xara.xml] for Xara X, Xara Xtreme and Xara LX
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/zoner-draw.xml zoner-draw.xml] for Zoner Draw 5

Moreover:

* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/right-handed-illustration.xml right-handed-illustration.xml] is a configuration where the user draw with the right hand and want to access all shortcuts with the left one
* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/keys/inkscape.xml inkscape.xml] is the default Inkscape shortcuts configuration file.

== Change the user interface ==

=== Change icons ===

Icons are in all in an ''icnos.svg'' file located in ''<Inkscape install directory>\share\icons\''. It can be overwritted or modified by the user (be sure of what you do).

Examples of existing ''icons.svg'':

* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/icons/icons.svg Default one] from the Inkscape repository
* A ''Tango Icon Set'' for Inkscape can be sent in the ''<Inkscape install directory>\share\icons\'' directory, you can rename it.
* [http://scnd101.deviantart.com/art/SimplyGrey-inkscape-theme-103497574 SimpleGrey inkscape theme] by Scnd101

=== Change the theme/skin ===

In GTK, a theme is defined in a '''gtkrc''' file. The Inkscape one is located in ''<Inkscape install directory>\etc\gtk-2.0''.

Customizing Inkscape

2012-12-28T15:29:47Z

Romain2Boss: Created page with "== Change keyboards shortcuts == There is no user interface to customize shortcuts yet but you can edit ''<Inkscape install directory>share/keys/default.xml''. == Change the..."

== Change keyboards shortcuts ==

There is no user interface to customize shortcuts yet but you can edit ''<Inkscape install directory>share/keys/default.xml''.

== Change the user interface ==

=== Change icons ===

Icons are in all in an ''icnos.svg'' file located in ''<Inkscape install directory>\share\icons\''. It can be overwritted or modified by the user (be sure of what you do).

Examples of existing ''icons.svg'':

* [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/share/icons/icons.svg Default one] from the Inkscape repository
* A ''Tango Icon Set'' for Inkscape can be sent in the ''<Inkscape install directory>\share\icons\'' directory, you can rename it.
* [http://scnd101.deviantart.com/art/SimplyGrey-inkscape-theme-103497574 SimpleGrey inkscape theme] by Scnd101

=== Change the theme/skin ===

In GTK, a theme is defined in a '''gtkrc''' file. The Inkscape one is located in ''<Inkscape install directory>\etc\gtk-2.0''.

Icons

2012-12-28T14:32:47Z

Romain2Boss: Add Icons category

This pages is a collection of information regarding the implementation of icons inside of Inkscape.

== Overview ==

Inkscape's interface makes extensive use of custom icons, and now provides a few mechanisms and different code to handle them. Over the years this area has seen distinct approaches taken, and has needs to move completely away from legacy approaches.

Aside from the state of the code, this section also covers some of the details on themes and how to and and implement icons, along with some of the internal details and design issues related to the implementation.

== History ==

Icon support in Inkscape has a long history and has accumulated a fair bit of cruft along the way. Originally the icons were custom widgets with all functionality shoved mainly into a single C source file. Standard GTK+ mechanisms had been originally avoided by a legacy design decree. However once the icon code was revisited that avoidance was dropped and work started (slightly sporadically) to move to standard GTK+ widgets and mechanisms. This includes the fact that the original SPIcon came from the GTK+ 1.x time frame, and predated GTK+ 2.x.

=== SPIcon ===

SPIcon was the original custom widget class used to represent icons, along with all the code needed to load the images to be used. A mix of pixmaps and then internally generated pixmaps from a common SVG was used.

So two main aspects exist here. First is the widget class itself that draws a visible image. Second is the code to load and cache the images used. Keep in mind that a single icon name might be used for several different sized display widgets.

=== Themeable Stock Icons ===

[http://library.gnome.org/devel/gtk/stable/gtk-Themeable-Stock-Images.html Themeable Stock Images] were added to GTK+ with the major jump to GTK+ 2.0. Some nice features were that they allowed a program to as for '''''logical''''' size icons and get different physical size images depending on how the user's overall theme was configured, could manage those multiple sizes, could store extra info such as name, and could have extra varients including right-to-left vs. left-to-right versions.

Probably the #1 usability item here is the support for '''''logical''''' sizes. So a program author can code in "get the menu-sized icon image" and get back a 16x16 image on one system, and get a 24x24 on a system with a high resolution display. ''OR'' the theme could also be set to return a 24x24 image for the low-res monitor in the cases where a '''''user''''' had eyesight that required a larger size.

Some work was begun to migrate Inkscape to use Themeable Stock Images, but the APIs themselves did not take into account that a program might want to provide it's own '''''scalable''''' set if images... and thus much prerendering was needed.

One of the more recent bits of coding on Themeable Stock Images support was to change things to not take the internal icons.svg versions, and instead fall to system icons when present. Much of this was done in coordination with Andreas Nilsson, Rodney Dawes Jakub Steiner and others to try to better support [http://tango.freedesktop.org/Tango_Desktop_Project Tango] and also the [http://tango.freedesktop.org/Standard_Icon_Naming_Specification Icon Naming Specification].

In order to maximize user benefit, applications should share common icons for common tasks. [http://www.freedesktop.org/ freedestop.org] listed out [http://www.freedesktop.org/wiki/Specifications/icon-naming-spec names for core "office"] functionality, but graphics and media programs were left out.

The intent was for authors of graphical and other artistic programs to list the common functionality needed and agree on names to use for the common concepts. This was the [http://tango.freedesktop.org/ArtLibreSet ArtLibreSet]. Unfortunately developers of other graphics projects did not care to share common icons, and Inkscape was one of the only ones to make suggestions.

=== GtkIconTheme (named icons) ===

[http://library.gnome.org/devel/gtk/stable/GtkIconTheme.html GtkIconTheme] was
added into GTK+ as of version 2.4. As to the difference from Themeable Stock Icons, the documentation mentions:

<blockquote>
"A good rule of thumb is that if there is a stock image for what you want to use, use it, otherwise use a named icon."
</blockquote>

Work was started in order to leverage GtkIconThem and it's "named icons" instead of custom Stock items, but has not quite been completed. One tricky aspect is that in order to manage a set of images for one icon at different sizes, it is still handy to place them into a stock object to hold them. However referencing them is not via stock ids, but rather name ids (which are different API calls for gtk widgets that use icons)

The main "gotcha" or shortcoming is that the named icons of GtkIconTheme use '''''physical''''' size only, and not logical size. As themes are loaded and changed, sizes also change so may cause issues.

=== XDG Base Directory Specification ===

The [http://standards.freedesktop.org/basedir-spec/latest/index.html XDG Base Directory Specification] lists how to identify sets of directories to use as base points for asset and file loading and storage.

GLib has [http://library.gnome.org/devel/glib/stable/glib-Miscellaneous-Utility-Functions.html supported this for some time], and among other things this allows an end user to switch config for applications at launch time, with the equivalent of an unlimited number of parallel installs with no conflicts and custom non-overlapping settings.

Specifically to issues of icons, the documentation for [http://library.gnome.org/devel/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir g_get_user_data_dir()] states:

<blockquote>
Returns a base directory in which to access application data such as icons that is customized for a particular user.
</blockquote>

One easily overlooked but '''''critical''''' aspect is that often users are not allowed to install things such as themes under /usr/, etc. In these cases installing into a user owned directory is an absolute must.

=== Themable Application-specific Icons ===

[http://live.gnome.org/ThemableAppSpecificIcons Themable Application-specific Icons] is a new ''proposed'' approach to allow for themeable icons specific to themselves without file and packaging conflicts.

One key item to note is that this is a separate/additional step to the base GTK technical solutions of Themeable Stock Icons and named icons.

Another point to consider is that the "${prefix}/share/<appname>" aspect of locations should be expanded in compliance with the [http://standards.freedesktop.org/basedir-spec/latest/index.html XDG Base Directory Specification].

== Design Goals ==

=== Usable ===

=== Aesthetically Pleasing ===

=== Themeable ===

=== Simple ===

=== Scalable ===

== Current Code ==

=== Debug Output ===

Debugging flags can be set in preferences.xml to enable various debugging.

<group
id="icons"
overlaySvg="1"
dumpDefault="1"
dumpSvg="1"
dumpGtk="1" />

{| border = "1"
|Name||Result
|-
|overlaySvg
|Overlays internally rendered SVG icons with dots spaced 4x4. Very helpful to determine if icon blurring is due to rendering or due to being stretched to fit.
|-
|dumpDefault
|Dumps informational g_message data default icon sizes.
|-
|dumpSvg
|Dumps informational g_message data related to internally rendered SVG icons.
|-
|dumpGtk
|Dumps informational g_message data related to stock GTK icons.
|}

=== Issues ===

The following are a few screenshots of problems observed with icons on various platforms and in various situations. Having a visual representation can help with understanding the issue.

==== Application Overriding System ====

[[File:icon_comp1.png|200px|thumb]]

This grab shows the independent "hicolor" icons on top, and the internal icons.svg icons on the bottom. In the case of independent icon case, they will override the system icons (rotate and flip in this case) on ''some'' versions of libs. In this particular case Inkscape itself is running on Ubuntu 8.10 and a high-visibility theme (so as to not be confused with our Tango icons).

In the independent icons case, they are overriding the system icons. Thus they are not just being hooked in to the fallback resolution as the final case. In the icons.svg case the orange arrows from the system are coming through as intended.

==== Dynamic Icons Missing ====

[[File:icon_comp2.png|200px|thumb]]

Also when running the application on an Ubuntu 8.10 box, it was seen that when the GTK+ theme was changed, the independent icons disappeared. The system-derived icons then came to be visible.

==== Dynamic Icons Missing from Menus ====

[[File:icon_comp3.png|200px|thumb]]

Also when running the application on an Ubuntu 8.10 box, it was seen that when the GTK+ theme was changed, the independent icons disappeared. The system-derived icons then came to be visible. This second screenshot show it occurring for the icons in the menus.

== Needed Improvements ==

== Themes ==

=== Single SVG File ===

[http://wiki.inkscape.org/wiki/index.php/ReleaseNotes042#Miscellaneous_usability Since Inkscape 0.42], icon themes could be installed by either changing the installed icons.svg or by installing a new

A requested background rendering of icons was added [http://wiki.inkscape.org/wiki/index.php/ReleaseNotes044#Speed as of Inkscape 0.44], and was a definite boost to usability.

If creating or editing an icons.svg file, it is recommended to do the following:

1) Adding the following to your preferences.xml will save quite a bit when it comes to file size produced.

<group
id="svgoutput"
usenamedcolors="0"
numericprecision="7"
minimumexponent="-8"
inlineattrs="1"
indent="0" />

2) Re-use/share gradients wherever possible.

3) Run File>Vaccuum Defs before saving it.

=== System and Single SVG ===

Initially the single SVG file icons would be used for everything. Later changes allowed for any stock icons known to be drawn from the installed system theme and override the internal ones from icons.svg

=== Fully Themeable ===

-- details pending --
[[User:JonCruz|JonCruz]]

== References ==

Also see [[ApplicationIcons]]

[[Category:Icons]]

Application icons

2012-12-28T14:30:57Z

Romain2Boss: Add Icons category

*[[TangoifiedIcons|Tangoified Inkscape Icon Set]]
*[[HowToEditIcons|How to Edit Icons]]
*[[IconsStyle|Icon Style]]
*<strike>[http://www.out-of-order.ca/inkscape-icon-tutorial/ A Beginner's tutorial on making icons in Inkscape]</strike>
*[http://developer.gnome.org/projects/gup/hig/2.0/icons.html Gnome HIG about icons]
*[http://developer.gnome.org/projects/gup/hig/2.0/design.html#Palette Colors for Gnome icons]
*<strike>[http://mmmaybe.gimp.org/tutorials/Creating_Icons/ "Creating Icons" tutorial from Jacub Steiner for GIMP]</strike>
*[http://jimmac.musichall.cz/ikony.php3 Jacub Steiners icons]
*[http://placide.home.sapo.pt/inkscape.html Plácido Sousa's crispy icon theme]
*[http://www.freeiconsweb.com Free Icons Library]

[[Category:Developer Discussion]]
[[Category:Needs Work]]
[[Category:Icons]]

Themable icons

2012-12-28T14:30:16Z

Romain2Boss: Add Icons category

This page lists the proposed icon names to be used by Inkscape when implementing Themable App Specific icons, described [http://live.gnome.org/ThemableAppSpecificIcons here].

We'll only use three contexts from the [http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html Icon Naming Specification]: Actions, Places, and Status.

The ALS/INS column says whether the icon name is present in either the [http://tango.freedesktop.org/ArtLibreSet Art Libre set] or the [http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html freedesktop.org Icon Naming Specification]. Ideally, it should be all green, but Inkscape requires a lot of special icons that may not be of much use to other applications.

==Actions==
{| class="wikitable sortable" border="1"
!Icon name
!Description
!Icon
!Tango
![[Art Libre Set|ALS]]/[[Icon Naming Specification|INS]]?
|-
|align-horizontal-baseline
|Align text baseline anchors horizontally
|[[Image:text-align-baseline-horizontal.png]]
|[[Image:text-align-baseline-horizontal-tango.png]]
|-
|align-horizontal-center
|Align center lines of objects horizontally
|[[Image:align-center-horizontal.png]]
|[[Image:align-center-horizontal-tango.png]]
|{{yes}}
|-
|align-horizontal-left
|Align left edges of objects
|[[Image:align-left.png]]
|[[Image:align-left-tango.png]]
|-
|align-horizontal-left-to-anchor
|Align left edges of objects to the right edge of an anchor object
|[[Image:align-left-to-anchor.png]]
|[[Image:align-left-to-anchor-tango.png]]
|-
|align-horizontal-right
|Align right edges of objects
|[[Image:align-right.png]]
|[[Image:align-right-tango.png]]
|-
|align-horizontal-right-to-anchor
|Align right edges of object to the left edge of an anchor object
|[[Image:align-right-to-anchor.png]]
|[[Image:align-right-to-anchor-tango.png]]
|-
|align-horizontal-node
|Align nodes horizontally
|[[Image:node-align-horizontal.png]]
|[[Image:node-align-horizontal-tango.png]]
|-
|align-vertical-baseline
|Align baselines of texts
|[[Image:text-align-baseline-vertical.png]]
|[[Image:text-align-baseline-vertical-tango.png]]
|-
|align-vertical-bottom
|Align bottom edges of objects
|[[Image:align-bottom.png]]
|[[Image:align-bottom-tango.png]]
|-
|align-vertical-bottom-to-anchor
|Align bottom edges of objects to the top edge of an anchor object
|[[Image:align-bottom-to-anchor.png]]
|[[Image:align-bottom-to-anchor-tango.png]]
|-
|align-vertical-center
|Align center lines of objects vertically
|[[Image:align-center-vertical.png]]
|[[Image:align-center-vertical-tango.png]]
|{{yes}}
|-
|align-vertical-node
|Align nodes vertically
|[[Image:node-align-vertical.png]]
|[[Image:node-align-vertical-tango.png]]
|-
|align-vertical-top
|Align top edges of objects
|[[Image:align-top.png]]
|[[Image:align-top-tango.png]]
|-
|align-vertical-top-to-anchor
|Align top edges of objects to the bottom edge of an anchor object
|[[Image:align-top-to-anchor.png]]
|[[Image:align-top-to-anchor-tango.png]]
|-
|bitmap-trace
|Trace (vectorize) a bitmap
|[[Image:bitmap-trace.png]]
|[[Image:bitmap-trace-tango.png]]
|-
|color-fill
|Paint Bucket tool
|[[Image:color-fill.png]]
|[[Image:color-fill-tango.png]]
|{{yes}}
|-
|color-gradient
|Gradient tool
|[[Image:color-gradient.png]]
|[[Image:color-gradient-tango.png]]
|{{yes}}
|-
|color-management
|Toggle color-managed view
|[[Image:view-manage-colors.png]]
|[[Image:color-management-tango.png]]
|{{yes}}
|-
|color-picker
|Color Picker (Dropper) tool
|[[Image:color-picker.png]]
|[[Image:color-picker-tango.png]]
|{{yes}}
|-
|distribute-graph-directed
|Neatly lay out the connector network as a directed graph
|[[Image:distribute-graph-directed.png]]
|[[Image:distribute-graph-directed-tango.png]]
|-
|distribute-graph
|Neatly lay out the connector network as an undirected graph
|[[Image:distribute-graph.png]]
|[[Image:distribute-graph-tango.png]]
|-
|distribute-horizontal-center
|Distribute the center lines of objects horizontally
|[[Image:distribute-horizontal-center.png]]
|[[Image:distribute-horizontal-center-tango.png]]
|{{yes}}
|-
|distribute-horizontal-gaps
|Make horizontal gaps between objects equal
|[[Image:distribute-horizontal-gaps.png]]
|[[Image:distribute-horizontal-gaps-tango.png]]
|-
|distribute-horizontal-left
|Distribute left edges of objects horizontally
|[[Image:distribute-horizontal-left.png]]
|[[Image:distribute-horizontal-left-tango.png]]
|{{yes}}
|-
|distribute-horizontal-node
|Distribute nodes horizontally
|[[Image:node-distribute-horizontal.png]]
|[[Image:node-distribute-horizontal-tango.png]]
|-
|distribute-horizontal-right
|Distribute right edges of objects horizontally
|[[Image:distribute-horizontal-right.png]]
|[[Image:distribute-horizontal-right-tango.png]]
|{{yes}}
|-
|distribute-randomize
|Place objects randomly
|[[Image:distribute-randomize.png]]
|[[Image:distribute-randomize-tango.png]]
|-
|distribute-remove-overlaps
|Rearrange objects so that they don't overlap each other
|[[Image:distribute-remove-overlaps.png]]
|[[Image:distribute-remove-overlaps-tango.png]]
|-
|distribute-unclump
|Rearrange objects so that they are equally spaced (center-to-center)
|[[Image:distribute-unclump.png]]
|[[Image:distribute-unclump-tango.png]]
|-
|distribute-vertical-bottom
|Distribute bottom edges of objects vertically
|[[Image:distribute-vertical-bottom.png]]
|[[Image:distribute-vertical-bottom-tango.png]]
|{{yes}}
|-
|distribute-vertical-center
|Distribute center lines of objects vertically
|[[Image:distribute-vertical-center.png]]
|[[Image:distribute-vertical-center-tango.png]]
|{{yes}}
|-
|distribute-vertical-gaps
|Make vertical gaps between objects equal
|[[Image:distribute-vertical-gaps.png]]
|[[Image:distribute-vertical-gaps-tango.png]]
|-
|distribute-vertical-node
|Distribute nodes vertically
|[[Image:node-distribute-vertical.png]]
|[[Image:node-distribute-vertical-tango.png]]
|-
|distribute-vertical-top
|Distriute top edges of objects vertically
|[[Image:distribute-vertical-top.png]]
|[[Image:distribute-vertical-top-tango.png]]
|{{yes}}
|-
|document-cleanup
|Remove unneeded definitions from the document (Vacuum Defs)
|[[Image:document-cleanup.png]]
|[[Image:document-cleanup-tango.png]]
|{{yes}}
|-
|document-export-ocal
|Export the document to the Open Clip Art Library
|[[Image:document-export-ocal.png]]
|[[Image:document-export-ocal-tango.png]]
|-
|document-export
|Export the document as a different format
|[[Image:document-export.png]]
|[[Image:document-export-tango.png]]
|-
|document-import-ocal
|Import a document from the Open Clip Art Library
|[[Image:document-import-ocal.png]]
|[[Image:document-import-ocal-tango.png]]
|-
|document-import
|Import a document or an image
|[[Image:document-import.png]]
|[[Image:document-import-tango.png]]
|-
|document-metadata
|Edit the document's metadata
|[[Image:document-metadata.png]]
|[[Image:document-metadata-tango.png]]
|-
|draw-calligraphic
|Calligraphy tool
|[[Image:draw-calligraphic.png]]
|[[Image:draw-calligraphic-tango.png]]
|{{yes}}
|-
|draw-connector
|Connector tool
|[[Image:draw-connector.png]]
|[[Image:draw-connector-tango.png]]
|-
|draw-cuboid
|3D Box tool
|[[Image:draw-cuboid.png]]
|[[Image:draw-cuboid-tango.png]]
|-
|draw-ellipse
|Ellipse tool
|[[Image:draw-ellipse.png]]
|[[Image:draw-ellipse-tango.png]]
|{{yes}}
|-
|draw-eraser
|Eraser tool
|[[Image:draw-eraser.png]]
|[[Image:draw-eraser-tango.png]]
|{{yes}}
|-
|draw-freehand
|Freehand tool (pencil)
|[[Image:draw-freehand.png]]
|[[Image:draw-freehand-tango.png]]
|{{yes}}
|-
|draw-path
|Pen tool
|[[Image:draw-path.png]]
|[[Image:draw-path-tango.png]]
|-
|draw-polygon-star
|Polygon / Star tool
|[[Image:draw-polygon-star.png]]
|[[Image:draw-polygon-star-tango.png]]
|-
|draw-rectangle
|Rectangle tool
|[[Image:draw-rectangle.png]]
|[[Image:draw-rectangle-tango.png]]
|{{yes}}
|-
|draw-spiral
|Spiral tool
|[[Image:draw-spiral.png]]
|[[Image:draw-spiral-tango.png]]
|-
|draw-text
|Text tool
|[[Image:draw-text.png]]
|[[Image:draw-text-tango.png]]
|{{yes}}
|-
|edit-clone
|Clone an object
|[[Image:edit-clone.png]]
|[[Image:edit-clone-tango.png]]
|-
|edit-clone-unlink
|Unlink a clone
|[[Image:edit-clone-unlink.png]]
|[[Image:edit-clone-unlink-tango.png]]
|-
|edit-duplicate
|Duplicate an object
|[[Image:edit-duplicate.png]]
|[[Image:edit-duplicate-tango.png]]
|-
|edit-paste-in-place
|Paste clipboard in place
|[[Image:edit-paste-in-place.png]]
|[[Image:edit-paste-in-place-tango.png]]
|-
|edit-paste-style
|Paste the style of the objects on the clipboard
|[[Image:edit-paste-style.png]]
|[[Image:edit-paste-style-tango.png]]
|-
|edit-select-all-layers
|Select all objects in all layers
|[[Image:edit-select-all-layers.png]]
|[[Image:edit-select-all-layers-tango.png]]
|-
|edit-select-invert
|Invert selection
|[[Image:edit-select-invert.png]]
|[[Image:edit-select-invert-tango.png]]
|-
|edit-select-none
|Select nothing (deselect)
|[[Image:edit-select-none.png]]
|[[Image:edit-select-none-tango.png]]
|-
|edit-select-original
|Select the original of a clone
|[[Image:edit-select-original.png]]
|[[Image:edit-select-original-tango.png]]
|-
|edit-undo-history
|View the undo history
|[[Image:edit-undo-history.png]]
|[[Image:edit-undo-history-tango.png]]
|-
|format-text-direction-horizontal
|
|[[Image:text-direction-horizontal.png]]
|[[Image:text-direction-horizontal-tango.png]]
|-
|format-text-direction-vertical
|
|[[Image:text-direction-vertical.png]]
|[[Image:text-direction-vertical-tango.png]]
|-
|help-keyboard-shortcuts
|Keyboard and mouse reference
|[[Image:help-keyboard-shortcuts.png]]
|[[Image:help-keyboard-shortcuts-tango.png]]
|-
|help-contents
|Inkscape Manual
|[[Image:help-manual.png]]
|[[Image:help-manual-tango.png]]
|{{yes}}
|-
|layer-bottom
|Move layer to the bottom
|[[Image:layer-bottom.png]]
|[[Image:layer-bottom-tango.png]]
|-
|layer-delete
|Delete layer
|[[Image:layer-delete.png]]
|[[Image:layer-delete-tango.png]]
|-
|layer-lower
|Move layer down
|[[Image:layer-lower.png]]
|[[Image:layer-lower-tango.png]]
|-
|layer-new
|Create a new layer
|[[Image:layer-new.png]]
|[[Image:layer-new-tango.png]]
|-
|layer-next
|Go to the layer below current
|[[Image:layer-next.png]]
|[[Image:layer-next-tango.png]]
|-
|layer-previous
|Go to the layer above current
|[[Image:layer-previous.png]]
|[[Image:layer-previous-tango.png]]
|-
|layer-raise
|Move layer up
|[[Image:layer-raise.png]]
|[[Image:layer-raise-tango.png]]
|-
|layer-rename
|Rename the layer
|[[Image:layer-rename.png]]
|[[Image:layer-rename-tango.png]]
|-
|layer-top
|Move layer to the top
|[[Image:layer-top.png]]
|[[Image:layer-top-tango.png]]
|-
|node-add
|Add a node
|[[Image:node-add.png]]
|[[Image:node-add-tango.png]]
|-
|node-break
|Split a node into two disjoint nodes
|[[Image:node-break.png]]
|[[Image:node-break-tango.png]]
|-
|node-delete-segment
|Remove a path segment between two nodes
|[[Image:node-delete-segment.png]]
|[[Image:node-delete-segment-tango.png]]
|-
|node-delete
|Delete a node
|[[Image:node-delete.png]]
|[[Image:node-delete-tango.png]]
|-
|node-join-segment
|Create a path segment between two nodes
|[[Image:node-join-segment.png]]
|[[Image:node-join-segment-tango.png]]
|-
|node-join
|Join two nodes into one
|[[Image:node-join.png]]
|[[Image:node-join-tango.png]]
|-
|object-flip-horizontal
|Flip horizontally (mirror)
|[[Image:object-flip-horizontal.png]]
|[[Image:object-flip-horizontal-tango.png]]
|-
|object-flip-vertical
|Flip vertically
|[[Image:object-flip-vertical.png]]
|[[Image:object-flip-vertical-tango.png]]
|-
|object-group
|Group selected objects
|[[Image:object-group.png]]
|[[Image:object-group-tango.png]]
|-
|object-rotate-left
|Rotate 90⁰ counter-clockwise
|[[Image:object-rotate-left.png]]
|[[Image:object-rotate-left-tango.png]]
|-
|object-rotate-right
|Rotate 90⁰ clockwise
|[[Image:object-rotate-right.png]]
|[[Image:object-rotate-right-tango.png]]
|-
|object-to-path
|Convert object to path
|[[Image:object-to-path.png]]
|[[Image:object-to-path-tango.png]]
|-
|object-tweak-attract
|Attract / repel objects (Tweak tool)
|[[Image:object-tweak-attract.png]]
|[[Image:object-tweak-attract-tango.png]]
|-
|object-tweak-blur
|Blur objects (Tweak tool)
|[[Image:object-tweak-blur.png]]
|[[Image:object-tweak-blur-tango.png]]
|-
|object-tweak-duplicate
|Duplicate objects (Tweak tool)
|[[Image:object-tweak-duplicate.png]]
|[[Image:object-tweak-duplicate-tango.png]]
|-
|object-tweak-jitter-color
|Jitter objects' colors (Tweak tool)
|[[Image:object-tweak-jitter-color.png]]
|[[Image:object-tweak-jitter-color-tango.png]]
|-
|object-tweak-paint
|Paint objects with the tool's color (Tweak tool)
|[[Image:object-tweak-paint.png]]
|[[Image:object-tweak-paint-tango.png]]
|-
|object-tweak-push
|Push / pull objects (Tweak tool)
|[[Image:object-tweak-push.png]]
|[[Image:object-tweak-push-tango.png]]
|-
|object-tweak-randomize
|Randomly displace objects (Tweak tool)
|[[Image:object-tweak-randomize.png]]
|[[Image:object-tweak-randomize-tango.png]]
|-
|object-tweak-rotate
|Rotate objects right / left (Tweak tool)
|[[Image:object-tweak-rotate.png]]
|[[Image:object-tweak-rotate-tango.png]]
|-
|object-tweak-shrink
|Shrink / grow objects (Tweak tool)
|[[Image:object-tweak-shrink.png]]
|[[Image:object-tweak-shrink-tango.png]]
|-
|object-ungroup
|Ungroup objects
|[[Image:object-ungroup.png]]
|[[Image:object-ungroup-tango.png]]
|-
|path-break-apart
|Break disjoint parts of a path into separate paths
|[[Image:path-break-apart.png]]
|[[Image:path-break-apart-tango.png]]
|-
|path-clip-edit
|Edit the clipping path of an object
|[[Image:path-clip-edit.png]]
|[[Image:path-clip-edit-tango.png]]
|-
|path-combine
|Merge paths into one
|[[Image:path-combine.png]]
|[[Image:path-combine-tango.png]]
|-
|path-cut
|Cut path
|[[Image:path-cut.png]]
|[[Image:path-cut-tango.png]]
|-
|path-difference
|Subtract one path from another
|[[Image:path-difference.png]]
|[[Image:path-difference-tango.png]]
|-
|path-division
|Divide path into disjoined parts where it intersects the second path
|[[Image:path-division.png]]
|[[Image:path-division-tango.png]]
|-
|path-effect-parameter-next
|Select next path parameter of a path effect
|[[Image:path-effect-parameter-next.png]]
|[[Image:path-effect-parameter-next-tango.png]]
|-
|path-exclusion
|Remove the common part of two paths
|[[Image:path-exclusion.png]]
|[[Image:path-exclusion-tango.png]]
|-
|path-inset
|Inset a path
|[[Image:path-inset.png]]
|[[Image:path-inset-tango.png]]
|-
|path-intersection
|Remove non-common parts of two paths
|[[Image:path-intersection.png]]
|[[Image:path-intersection-tango.png]]
|-
|path-mask-edit
|Edit the masking path of an object
|[[Image:path-mask-edit.png]]
|[[Image:path-mask-edit-tango.png]]
|-
|path-offset-dynamic
|Create an adjustable offset
|[[Image:path-offset-dynamic.png]]
|[[Image:path-offset-dynamic-tango.png]]
|-
|path-offset-linked
|Create a linked offset that updates whenever the linked path changes
|[[Image:path-offset-linked.png]]
|[[Image:path-offset-linked-tango.png]]
|-
|path-outset
|Outset a path
|[[Image:path-outset.png]]
|[[Image:path-outset-tango.png]]
|-
|path-reverse
|Reverse the direction of the path
|[[Image:path-reverse.png]]
|[[Image:path-reverse-tango.png]]
|-
|path-simplify
|Simplify the path
|[[Image:path-simplify.png]]
|[[Image:path-simplify-tango.png]]
|-
|path-tweak-attract
|Attract / repel paths
|[[Image:path-tweak-attract.png]]
|[[Image:path-tweak-attract-tango.png]]
|-
|path-tweak-push
|Push paths
|[[Image:path-tweak-push.png]]
|[[Image:path-tweak-push-tango.png]]
|-
|path-tweak-roughen
|roughen paths
|[[Image:path-tweak-roughen.png]]
|[[Image:path-tweak-roughen-tango.png]]
|-
|path-tweak-shrink
|Shrink / grow paths
|[[Image:path-tweak-shrink.png]]
|[[Image:path-tweak-shrink-tango.png]]
|-
|path-union
|Union paths
|[[Image:path-union.png]]
|[[Image:path-union-tango.png]]
|-
|rectangle-make-corners-sharp
|Remove rounded corners from a rectangle
|[[Image:rectangle-make-corners-sharp.png]]
|[[Image:rectangle-make-corners-sharp-tango.png]]
|-
|selection-bottom
|Move selection to the bottom
|[[Image:selection-bottom.png]]
|[[Image:selection-bottom-tango.png]]
|-
|selection-lower
|Move selection down
|[[Image:selection-lower.png]]
|[[Image:selection-lower-tango.png]]
|-
|selection-make-bitmap-copy
|Create a bitmap copy of the selected objects
|[[Image:selection-make-bitmap-copy.png]]
|[[Image:selection-make-bitmap-copy-tango.png]]
|-
|selection-move-to-layer-above
|Move the selection one layer up
|[[Image:selection-move-to-layer-above.png]]
|[[Image:selection-move-to-layer-above-tango.png]]
|-
|selection-move-to-layer-below
|Move selection one layer down
|[[Image:selection-move-to-layer-below.png]]
|[[Image:selection-move-to-layer-below-tango.png]]
|-
|selection-raise
|Move selection up
|[[Image:selection-raise.png]]
|[[Image:selection-raise-tango.png]]
|-
|selection-top
|Move selection to the top
|[[Image:selection-top.png]]
|[[Image:selection-top-tango.png]]
|-
|show-dialogs
|Show / hide dialogs
|[[Image:show-dialogs.png]]
|[[Image:show-dialogs-tango.png]]
|-
|show-grid
|Toggle grid
|[[Image:show-grid.png]]
|[[Image:show-grid-tango.png]]
|{{yes}}
|-
|show-guides
|Toggle guides
|[[Image:show-guides.png]]
|[[Image:show-guides-tango.png]]
|{{yes}}
|-
|stroke-to-path
|Convert the object's stroke to a path
|[[Image:stroke-to-path.png]]
|[[Image:stroke-to-path-tango.png]]
|-
|text-convert-to-regular
|Convert flowed text to regular text
|[[Image:text-convert-to-regular.png]]
|[[Image:text-convert-to-regular-tango.png]]
|-
|distribute-horizontal-baseline
|Distribute text baseline anchors horizontally
|[[Image:text-distribute-baseline-horizontal.png]]
|[[Image:text-distribute-baseline-horizontal-tango.png]]
|-
|distribute-vertical-baseline
|Distribute text baseline anchors vertically
|[[Image:text-distribute-baseline-vertical.png]]
|[[Image:text-distribute-baseline-vertical-tango.png]]
|-
|text-flow-into-frame
|Flow text into a path frame
|[[Image:text-flow-into-frame.png]]
|[[Image:text-flow-into-frame-tango.png]]
|-
|text-put-on-path
|Put text on a path
|[[Image:text-put-on-path.png]]
|[[Image:text-put-on-path-tango.png]]
|-
|text-remove-from-path
|Remove text from a path
|[[Image:text-remove-from-path.png]]
|[[Image:text-remove-from-path-tango.png]]
|-
|text-unflow
|Remove text from a flow frame
|[[Image:text-unflow.png]]
|[[Image:text-unflow-tango.png]]
|-
|text-unkern
|Remove manual kerning
|[[Image:text-unkern.png]]
|[[Image:text-unkern-tango.png]]
|-
|tool-node-editor
|Node tool
|[[Image:tool-node-editor.png]]
|[[Image:tool-node-editor-tango.png]]
|-
|tool-pointer
|Select tool
|[[Image:tool-pointer.png]]
|[[Image:tool-pointer-tango.png]]
|-
|tool-tweak
|Tweak tool
|[[Image:tool-tweak.png]]
|[[Image:tool-tweak-tango.png]]
|-
|transform-move-horizontal
|Move object horizontally (Transform dialog)
|[[Image:transform-move-horizontal.png]]
|[[Image:transform-move-horizontal-tango.png]]
|-
|transform-move-vertical
|Move object vertically (Transform dialog)
|[[Image:transform-move-vertical.png]]
|[[Image:transform-move-vertical-tango.png]]
|-
|transform-rotate
|Rotate an object (Transform dialog)
|[[Image:transform-rotate.png]]
|[[Image:transform-rotate-tango.png]]
|{{yes}}
|-
|transform-scale-horizontal
|Scale an object horizontally (Transform dialog)
|[[Image:transform-scale-horizontal.png]]
|[[Image:transform-scale-horizontal-tango.png]]
|-
|transform-scale-vertical
|Scale an object vertically (Transform dialog)
|[[Image:transform-scale-vertical.png]]
|[[Image:transform-scale-vertical-tango.png]]
|-
|transform-skew-horizontal
|Skew an object horizontally (Transform dialog)
|[[Image:transform-skew-horizontal.png]]
|[[Image:transform-skew-horizontal-tango.png]]
|-
|transform-skew-vertical
|Skew an object vertically (Transform dialog)
|[[Image:transform-skew-vertical.png]]
|[[Image:transform-skew-vertical-tango.png]]
|-
|window-next
|Next window
|[[Image:window-next.png]]
|[[Image:window-next-tango.png]]
|-
|window-previous
|Previous window
|[[Image:window-previous.png]]
|[[Image:window-previous-tango.png]]
|-
|xml-attribute-delete
|Delete an XML attribute
|[[Image:xml-attribute-delete.png]]
|[[Image:xml-attribute-delete-tango.png]]
|-
|xml-element-new
|Create an XML element node
|[[Image:xml-element-new.png]]
|[[Image:xml-element-new-tango.png]]
|-
|xml-node-delete
|Delete an XML node
|[[Image:xml-node-delete.png]]
|[[Image:xml-node-delete-tango.png]]
|-
|xml-node-duplicate
|Duplicate an XML node
|[[Image:xml-node-duplicate.png]]
|[[Image:xml-node-duplicate-tango.png]]
|-
|xml-text-new
|Create an XML text node
|[[Image:xml-text-new.png]]
|[[Image:xml-text-new-tango.png]]
|-
|zoom-double-size
|Zoom 2:1
|[[Image:zoom-double-size.png]]
|[[Image:zoom-double-size-tango.png]]
|-
|zoom-fit-drawing
|Zoom to fit objects on the page
|[[Image:zoom-fit-drawing.png]]
|[[Image:zoom-fit-drawing-tango.png]]
|-
|zoom-fit-page
|Zoom to fit page
|[[Image:zoom-fit-page.png]]
|[[Image:zoom-fit-page-tango.png]]
|-
|zoom-fit-selection
|Zoom to fit selection
|[[Image:zoom-fit-selection.png]]
|[[Image:zoom-fit-selection-tango.png]]
|-
|zoom-fit-width
|Zoom to fit the page's width
|[[Image:zoom-fit-width.png]]
|[[Image:zoom-fit-width-tango.png]]
|-
|zoom-half-size
|Zoom 1:2
|[[Image:zoom-half-size.png]]
|[[Image:zoom-half-size-tango.png]]
|-
|zoom-in
|Increase zoom
|[[Image:zoom-in.png]]
|[[Image:zoom-in-tango.png]]
|-
|zoom-next
|Redo zoom
|[[Image:zoom-next.png]]
|[[Image:zoom-next-tango.png]]
|-
|zoom-original
|Zoom 1:1
|[[Image:zoom-original.png]]
|[[Image:zoom-original-tango.png]]
|-
|zoom-out
|Decrease zoom
|[[Image:zoom-out.png]]
|[[Image:zoom-out-tango.png]]
|-
|zoom-previous
|Undo zoom
|[[Image:zoom-previous.png]]
|[[Image:zoom-previous-tango.png]]
|-
|zoom
|Zoom tool
|[[Image:zoom.png]]
|[[Image:zoom-tango.png]]
|}

==Places==
{| class="wikitable" border="1"
!Icon name
!Description
!Icon
!Tango
!ALS/INS?
|-
|dialog-align-and-distribute
|Align and Distribute dialog
|[[Image:dialog-align-and-distribute.png]]
|[[Image:dialog-align-and-distribute-tango.png]]
|-
|dialog-fill-and-stroke
|Fill and Stroke dialog
|[[Image:dialog-fill-and-stroke.png]]
|[[Image:dialog-fill-and-stroke-tango.png]]
|-
|dialog-icon-preview
|Icon Preview dialog
|[[Image:dialog-icon-preview.png]]
|[[Image:dialog-icon-preview-tango.png]]
|-
|dialog-input-devices
|Input Devices dialog
|[[Image:dialog-input.png]]
|[[Image:dialog-input-tango.png]]
|-
|dialog-layers
|Layers dialog
|[[Image:dialog-layers.png]]
|[[Image:dialog-layers-tango.png]]
|-
|dialog-memory
|About Memory dialog
|[[Image:dialog-memory.png]]
|[[Image:dialog-memory-tango.png]]
|-
|dialog-messages
|Messages dialog (message stack)
|[[Image:dialog-messages.png]]
|[[Image:dialog-messages-tango.png]]
|-
|dialog-object-properties
|Object Properties dialog
|[[Image:dialog-object-properties.png]]
|[[Image:dialog-object-properties-tango.png]]
|-
|dialog-rows-and-columns
|Rows and Columns dialog (grid arrange)
|[[Image:dialog-rows-and-columns.png]]
|[[Image:dialog-rows-and-columns-tango.png]]
|-
|dialog-scripts
|Scripts dialog
|[[Image:dialog-scripts.png]]
|[[Image:dialog-scripts-tango.png]]
|-
|dialog-text-and-font
|Text and Font dialog
|[[Image:dialog-text-and-font.png]]
|[[Image:dialog-text-and-font-tango.png]]
|-
|dialog-tile-clones
|Create Tiled Clones dialog
|[[Image:dialog-tile-clones.png]]
|[[Image:dialog-tile-clones-tango.png]]
|-
|dialog-transform
|Apply an arbitrary transformation to an object
|[[Image:object-transform.png]]
|[[Image:object-transform-tango.png]]
|-
|dialog-xml-editor
|XML Editor dialog
|[[Image:dialog-xml-editor.png]]
|[[Image:dialog-xml-editor-tango.png]]
|-
|grid-axonometric
|Axonometric grid
|[[Image:grid-axonometric.png]]
|[[Image:grid-axonometric-tango.png]]
|-
|grid-rectangular
|Rectangular (XY) grid
|[[Image:grid-rectangular.png]]
|[[Image:grid-rectangular-tango.png]]
|-
|guides
|
|[[Image:guides.png]]
|[[Image:show-guides-tango.png]]
|-
|object-columns
|
|[[Image:object-columns.png]]
|[[Image:object-columns-tango.png]]
|-
|object-rows
|
|[[Image:object-rows.png]]
|[[Image:object-rows-tango.png]]
|}

==Status==
{| class="wikitable" border="1"
!Icon name
!Description
!Icon
!Tango
!ALS/INS?
|-
|connector-avoid
|
|[[Image:connector-avoid.png]]
|[[Image:connector-avoid-tango.png]]
|-
|connector-ignore
|
|[[Image:connector-ignore.png]]
|[[Image:connector-ignore-tango.png]]
|-
|draw-ellipse-arc
|Arc mode of the Ellipse tool
|[[Image:draw-ellipse-arc.png]]
|[[Image:draw-ellipse-arc-tango.png]]
|-
|draw-ellipse-segment
|Segment mode of the Ellipse tool
|[[Image:draw-ellipse-segment.png]]
|[[Image:draw-ellipse-segment-tango.png]]
|-
|draw-ellipse-whole
|Draw whole ellipses instead of arcs or segments
|[[Image:draw-ellipse-whole.png]]
|[[Image:draw-ellipse-whole-tango.png]]
|-
|draw-eraser-delete-objects
|
|[[Image:draw-eraser-delete-objects.png]]
|[[Image:draw-eraser-delete-objects-tango.png]]
|-
|draw-polygon
|Polygon mode of the Polygon tool
|[[Image:draw-polygon.png]]
|[[Image:draw-polygon-tango.png]]
|{{yes}}
|-
|draw-star
|Star mode of the Polygon tool
|[[Image:draw-star.png]]
|[[Image:draw-star-tango.png]]
|{{yes}}
|-
|draw-trace-background
|Trace background lightness with the stroke width
|[[Image:draw-trace-background.png]]
|[[Image:draw-trace-background-tango.png]]
|-
|draw-use-pressure
|Use pressure reading from tablet when drawing
|[[Image:draw-use-pressure.png]]
|[[Image:draw-use-pressure-tango.png]]
|-
|draw-use-tilt
|Use tilt reading from the tablet when drawing
|[[Image:draw-use-tilt.png]]
|[[Image:draw-use-tilt-tango.png]]
|-
|fill-rule-even-odd
|
|[[Image:fill-rule-even-odd.png]]
|[[Image:fill-rule-even-odd-tango.png]]
|-
|fill-rule-nonzero
|
|[[Image:fill-rule-nonzero.png]]
|[[Image:fill-rule-nonzero-tango.png]]
|-
|node-segment-curve
|
|[[Image:node-segment-curve.png]]
|[[Image:node-segment-curve-tango.png]]
|-
|node-segment-line
|
|[[Image:node-segment-line.png]]
|[[Image:node-segment-line-tango.png]]
|-
|node-type-auto-smooth
|
|[[Image:node-type-auto-smooth.png]]
|[[Image:node-type-auto-smooth-tango.png]]
|-
|node-type-cusp
|
|[[Image:node-type-cusp.png]]
|[[Image:node-type-cusp-tango.png]]
|-
|node-type-smooth
|
|[[Image:node-type-smooth.png]]
|[[Image:node-type-smooth-tango.png]]
|-
|node-type-symmetric
|
|[[Image:node-type-symmetric.png]]
|[[Image:node-type-symmetric-tango.png]]
|-
|object-fill
|
|[[Image:object-fill.png]]
|[[Image:object-fill-tango.png]]
|-
|object-hidden
|Object or layer is invisible
|[[Image:object-hidden.png]]
|[[Image:object-hidden-tango.png]]
|-
|object-locked
|Object or layer cannot be modified
|[[Image:object-locked.png]]
|[[Image:object-locked-tango.png]]
|-
|object-stroke-style
|
|[[Image:object-stroke-style.png]]
|[[Image:object-stroke-style-tango.png]]
|-
|object-stroke
|
|[[Image:object-stroke.png]]
|[[Image:object-stroke-tango.png]]
|-
|object-unlocked
|Object or layer can be modified
|[[Image:object-unlocked.png]]
|[[Image:object-unlocked-tango.png]]
|-
|object-visible
|Object or layer is visible
|[[Image:object-visible.png]]
|[[Image:object-visible-tango.png]]
|-
|paint-gradient-linear
|
|[[Image:fill-gradient-linear.png]]
|[[Image:fill-gradient-linear-tango.png]]
|-
|paint-gradient-radial
|
|[[Image:fill-gradient-radial.png]]
|[[Image:fill-gradient-radial-tango.png]]
|-
|paint-none
|Paint is set to empty
|[[Image:fill-none.png]]
|[[Image:fill-none-tango.png]]
|-
|paint-pattern
|Pattern paint
|[[Image:fill-pattern.png]]
|[[Image:fill-pattern-tango.png]]
|-
|paint-solid
|Single color solid paint
|[[Image:fill-flat.png]]
|[[Image:fill-flat-tango.png]]
|-
|paint-unknown
|Paint is inherited or unknown
|[[Image:fill-unknown.png]]
|[[Image:fill-unknown-tango.png]]
|-
|path-mode-bezier
|
|[[Image:path-mode-bezier.png]]
|[[Image:path-mode-bezier-tango.png]]
|-
|path-mode-polyline
|
|[[Image:path-mode-segments.png]]
|[[Image:path-mode-segments-tango.png]]
|-
|path-mode-polyline-paraxial
|
|[[Image:path-mode-paraxial-segments.png]]
|[[Image:path-mode-paraxial-segments-tango.png]]
|-
|path-mode-spiro
|
|[[Image:path-mode-spiro.png]]
|[[Image:path-mode-spiro-tango.png]]
|-
|perspective-parallel
|Toggle whether an axis in a perspective has a vanishing point
|[[Image:perspective-parallel.png]]
|[[Image:perspective-parallel-tango.png]]
|-
|snap
|Global snap toggle
|[[Image:snap.png]]
|[[Image:snap-tango.png]]
|-
|snap-bounding-box
|Toggle bounding box snapping
|[[Image:snap-bounding-box.png]]
|[[Image:snap-bounding-box-tango.png]]
|-
|snap-bounding-box-center
|Toggle snapping between bounding box centers
|[[Image:snap-bounding-box-center.png]]
|[[Image:snap-bounding-box-center-tango.png]]
|-
|snap-bounding-box-corners
|Toggle snapping between bounding box corners
|[[Image:snap-bounding-box-corners.png]]
|[[Image:snap-bounding-box-corners-tango.png]]
|-
|snap-bounding-box-edges
|Toggle snapping between bounding box edges
|[[Image:snap-bounding-box-edges.png]]
|[[Image:snap-bounding-box-edges-tango.png]]
|-
|snap-bounding-box-midpoints
|Toggle snapping between bounding box edge midpoints
|[[Image:snap-bounding-box-midpoints.png]]
|[[Image:snap-bounding-box-midpoints-tango.png]]
|-
|snap-grid-guide-intersections
|Toggle snapping to intersections between the grid and guides
|[[Image:snap-grid-guide-intersections.png]]
|[[Image:snap-grid-guide-intersections-tango.png]]
|-
|snap-nodes
|Toggle snapping nodes
|[[Image:snap-nodes.png]]
|[[Image:snap-nodes-tango.png]]
|-
|snap-nodes-center
|Toggle snapping nodes to centers of objects
|[[Image:snap-nodes-center.png]]
|[[Image:snap-nodes-center-tango.png]]
|-
|snap-nodes-cusp
|Toggle snapping nodes to cusp nodes
|[[Image:snap-nodes-cusp.png]]
|[[Image:snap-nodes-cusp-tango.png]]
|-
|snap-nodes-intersection
|Toggle snapping nodes to intersections
|[[Image:snap-nodes-intersection.png]]
|[[Image:snap-nodes-intersection-tango.png]]
|-
|snap-nodes-midpoint
|Toggle snapping nodes to edge midpoints
|[[Image:snap-nodes-midpoint.png]]
|[[Image:snap-nodes-midpoint-tango.png]]
|-
|snap-nodes-path
|Toggle snapping nodes to paths
|[[Image:snap-nodes-path.png]]
|[[Image:snap-nodes-path-tango.png]]
|-
|snap-nodes-rotation-center
|Toggle snapping nodes to rotation centers of objects
|[[Image:snap-nodes-rotation-center.png]]
|[[Image:snap-nodes-rotation-center-tango.png]]
|-
|snap-nodes-smooth
|Togle snapping nodes to smooth nodes
|[[Image:snap-nodes-smooth.png]]
|[[Image:snap-nodes-smooth-tango.png]]
|-
|snap-page
|Toggle snapping to page border
|[[Image:snap-page.png]]
|[[Image:snap-page-tango.png]]
|-
|stroke-cap-butt
|
|[[Image:stroke-cap-butt.png]]
|[[Image:stroke-cap-butt-tango.png]]
|{{yes}}
|-
|stroke-cap-round
|
|[[Image:stroke-cap-round.png]]
|[[Image:stroke-cap-round-tango.png]]
|{{yes}}
|-
|stroke-cap-square
|
|[[Image:stroke-cap-square.png]]
|[[Image:stroke-cap-square-tango.png]]
|{{yes}}
|-
|stroke-join-bevel
|
|[[Image:stroke-join-bevel.png]]
|[[Image:stroke-join-bevel-tango.png]]
|{{yes}}
|-
|stroke-join-miter
|
|[[Image:stroke-join-miter.png]]
|[[Image:stroke-join-miter-tango.png]]
|{{yes}}
|-
|stroke-join-round
|
|[[Image:stroke-join-round.png]]
|[[Image:stroke-join-round-tango.png]]
|{{yes}}
|-
|transform-affect-gradient
|Transform gradients along with objects
|[[Image:transform-affect-gradient.png]]
|[[Image:transform-affect-gradient-tango.png]]
|-
|transform-affect-pattern
|Transform patterns along with objects
|[[Image:transform-affect-pattern.png]]
|[[Image:transform-affect-pattern-tango.png]]
|-
|transform-affect-rounded-corners
|Transform rounded corners along with rectangles
|[[Image:transform-affect-rounded-corners.png]]
|[[Image:transform-affect-rounded-corners-tango.png]]
|-
|transform-affect-stroke
|Scale stroke width when transforming
|[[Image:transform-affect-stroke.png]]
|[[Image:transform-affect-stroke-tango.png]]
|}

[[Category:Icons]]

User Interface Modules

2012-12-26T15:18:17Z

Romain2Boss: /* Dialogs */

Discussion and documentation about specific Inkscape dialogs, widgets, tools and more inside the [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/ src/ui] directory.

== Dialogs ==

By extension, a '''dialog''' in Inkscape vocabulary is any type of window, i.e. a set of widgets with an OS decoration, a title...

All dialogs are in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/dialog src/ui/dialog] (except for old dialogs).

* [[About Dialog]]: The ''About Inkscape'' dialog
* [[Align and Distribute Dialog]]: The ''Align and distribute'' dialog
* [[Class Inkscape::UI::Dialog::Behavior::Behavior]]
* [[Class Inkscape::UI::Dialog::Behavior::DockBehavior]]
* [[Class Inkscape::UI::Dialog::Behavior::FloatingBehavior]]
* [[Class Inkscape::UI::Dialog::CaligraphicProfileRename]]
* [[Close Dialog]]
* [[Class Inkscape::UI::Dialog::ColorItem]]
* [[Class Inkscape::UI::Dialog::DebugDialog]]
* [[Class Inkscape::UI::Dialog::DesktopTracker]]
* [[Class Inkscape::UI::Dialog::Dialog]]
* [[Class Inkscape::UI::Dialog::DialogManager]]
* [[Class Inkscape::UI::Dialog::DocumentMetadata]]: The ''Document metadatas'' dialog
** [[Andrews Big Dialog Re-Design/Document Metadata]]
* [[Class Inkscape::UI::Dialog::DocumentProperties]]: The ''Document properties'' dialog
* [[Class Inkscape::UI::Dialog::ExtensionEditor]]
* [[Class Inkscape::UI::Dialog::ExtensionPanel]]
* [[Export Bitmap Dialog]]
** [[Export Bitmap Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/Export Bitmap]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseGtk]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseWin32]]
* [[Class Inkscape::UI::Dialog::FileDialogOCALBase]]
* [[Class Inkscape::UI::Dialog::FileImportFromOCALDialog]]
* [[Class Inkscape::UI::Dialog::FileListViewText]]
* [[Class Inkscape::UI::Dialog::FileOpenDialog]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileSaveDialog]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileExportDialog]]
* [[Class Inkscape::UI::Dialog::FileExportDialogImpl]]
* [[Stroke Dialog]]
** [[Fill and Stroke Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::FilterEffectsDialog]]
* [[Find Dialog]]
* [[Class Inkscape::UI::Dialog::GlyphsPanel]]
* [[Class Inkscape::UI::Dialog::GuidelinePropertiesDialog]]
* [[Class Inkscape::UI::Dialog::IconPreviewPanel]]
* [[Image Properties Dialog]]
** [[Image properties dialog enhancements]]
* [[Class Inkscape::UI::Dialog::InkscapePreferences]]: The ''Inkscape preferences'' dialog
* [[Class Inkscape::UI::Dialog::InputDialog]]
* [[Layer Dialog]]
* [[Class Inkscape::UI::Dialog::LayerPropertiesDialog]]: The ''Layer properties'' dialog
* [[Class Inkscape::UI::Dialog::LayersPanel]]
* [[Class Inkscape::UI::Dialog::LivePathEffectEditor]]
* [[New Document Dialog]]
* [[Memory Dialog]]
* [[Messages Dialog]]
* [[OCAL Dialog]]
** [[OCAL Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/OCAL]]
* [[Class Inkscape::UI::Dialog::PanelDialogBase]]
* [[Print Dialog]]: The ''Print...'' dialog
* [[Class Inkscape::UI::Dialog::PrintColorsPreviewDialog]]
* [[Script Dialog]]
* [[Class Inkscape::UI::Dialog::SvgFontsDialog]]
* [[Class Inkscape::UI::Dialog::SVGPreview]]
* [[Class Inkscape::UI::Dialog::SwatchesPanel]]
* [[SymbolsDialog|Symbols Dialog]]
* [[Tablet Dialog]]
* [[Text Dialog]]
* [[Tile Dialog]]
* [[Class Inkscape::UI::Dialog::TraceDialog]]
** [[Trace Bitmap Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::Transformation]]
* [[Class Inkscape::UI::Dialog::UndoHistory]]: The ''Undo history'' dialog

Dialogs that have not yet been rewritted can be found in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/dialogs src/dialogs].

=== Others re-designs ===

* [[Andrews Big Dialog Re-Design]]
* [[Andrews Big Dialog Re-Design/Embed or Link]]
* [[FindReplaceDialog]]
* [[DialogsReorganization]]

== Widgets ==

Widgets are implemented in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/widget src/ui/widget].

* [[Class Inkscape::UI::Widget::ColorPreview]]: A simple color preview widget, mainly used within a picker button
* [[Class Inkscape::UI::Widget::ProgressPannel]]
* [[Class Inkscape::UI::Widget::SpinButton]]: Widget that allows entry of simple math expressions (also units, when linked with UnitMenu), and allows entry of both '.' and ',' for the decimal, even when in numeric mode
* [[Class Inkscape::UI::Widget::SpinSlider]]: Groups an Gtk::HScale and a Inkscape::UI::Widget::SpinButton together using the same Adjustment
* ...

Also a proposal for a [[Color Entry Widget|Color Entry]].

== src/ui/tools ==
* ...

== Toolbars ==

A '''toolbar''' is a set of graphical widgets put around the canvas to provide actions on objects, canvas or documents.

See [[Toolbar]] page for more informations.

== Menu ==

See [[Menu]].

[[Category:Developer Documentation]]

Gwyn

2012-12-26T15:05:06Z

Romain2Boss: Links

[[Galleries|Back to Galleries]]

A drawing to test the possibilities of Inkscape

upload:cellulare.png

Cellphone

Original is approx 5cm x 11cm Inkscape svg; available for [http://inkscape.org/wiki_uploads/cellulare.svg download]. It displays well in ksvg but, predictably, is a mess in Scribus (fonts and multiple complex gradients).

Here's a whimsical chip

upload:Chip.png

Chip

For some reason this one, although less complex, does not display well in ksvg (nor Scribus). Here's the [http://inkscape.org/wiki_uploads/Chip.svg source] for anyone who's interested.

Pete Burrows (gwynsoft@tin.it)

Good work! The cellphone renders perfectly in Batik/Adobe, but the chip has a problem with fill-opacity on a gradient in 0.40 and in Batik/Adobe, due to a bug in 0.39. See Known Issues at http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes for more details and a workaround.

Thanks for the comment. I tried the workaround and it worked well in both ksvg and Scribus, but showed up some other minor problems - looks like I'll have to try this one again... (looking forward to 0.40 in Gentoo).

PB

[[Category:Needs Work]]

CompilingMandrake

2012-12-26T15:00:54Z

Romain2Boss: /* Building RPM Package on Mandrakelinux 10.1 */ Links

== Building RPM Package on Mandrakelinux 10.1 ==

I did it with the src.rpm package available at sf.net.
The RPM rebuild process is pretty similar to compiling from source but first we need to satisfy the dependencies (the fastest way is Mandrakelinux's ''urpmi''):

# download the [http://prdownloads.sourceforge.net/inkscape/inkscape-0.41-1.src.rpm?download download Inkscape's src.rpm] at sourceforge.net
# <code>urpmi gtk2-devel</code> (Inkscape 0.41 needs gtk2-devel >= 2.4.0; use [http://easyurpmi.zarb.org/ urpmi source "main"] if you haven't got a CD/DVD with devel packages)
# <code>urpmi libpng3</code> (libpng >= 1.2 is needed)
# now the '''libgc 6.4+''' is needed. I didn't found or somewhat missed the [http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/ Hans Boehm's gc] package for mdk 10.1, so i downloaded and compiled it like this: <pre>./configure --prefix=/usr
make
su
make install</pre> (in fact i used <code>checkinstall</code> instead of <code>make install</code> and then <code>urpmi /usr/src/RPM/RPMS/i586/gc-6.4-1luc.i586.rpm</code>)
# <code>urpmi libxml2-devel</code>
# <code>urpmi libxslt-devel</code>
# <code>urpmi libsigc++2.0_0-devel</code> (to be found at urpmi source "contrib")
# <code>urpmi libgtkmm2.4_1-devel</code> (also urpmi source "contrib")
# <code>urpmi popt-devel</code> (urpmi source "main")
# finally you can perform successfully: <code>rpm -rebuild inkscape-0.41-1.src.rpm</code> (the resulting RPM package will be probably stored as <code>/usr/src/RPM/RPMS/i586/inkscape-0.41-1.i586.rpm</code> according to your RPM settings)

''luci''

Update by Chris Hill ubergeek at ubergeek dawt tv

I had some success with this method, but a couple issues:
The RPM would die on build because of an 'unpacked file'. So I ended up adding this to the spec file in /usr/src/RPM/SPECS

<code>%define _unpackaged_files_terminate_build 0</code>

I had other dependencies that I could not resolve easily:

<code>
libgc.so.1 is needed by inkscape-0.42-0

perl(XML::XQL) is needed by inkscape-0.42-0

perl(XML::XQL::DOM) is needed by inkscape-0.42-0

</code>
And I had indeed installed libgc, so I ended up installing with nodeps:

rpm -ivh --nodeps inkscape-0.42-0.i586.rpm 

Seems to be working fine (its so fast!!), but I might be missing perl/python support.

The HTML needs to be removed.
[[Category:Developer Documentation]]
[[Category:Needs Work]]

CompilingMandrake

2012-12-26T15:00:27Z

Romain2Boss: Links

== Building RPM Package on Mandrakelinux 10.1 ==

I did it with the src.rpm package available at sf.net.
The RPM rebuild process is pretty similar to compiling from source but first we need to satisfy the dependencies (the fastest way is Mandrakelinux's ''urpmi''):

# download the [http://prdownloads.sourceforge.net/inkscape/inkscape-0.41-1.src.rpm?download download Inkscape's src.rpm] at sourceforge.net
# <code>urpmi gtk2-devel</code> (Inkscape 0.41 needs gtk2-devel >= 2.4.0; use [http://easyurpmi.zarb.org/ urpmi source "main"] if you haven't got a CD/DVD with devel packages)
# <code>urpmi libpng3</code> (libpng >= 1.2 is needed)
# now the '''libgc 6.4+''' is needed. I didn't found or somewhat missed the [http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/ Hans Boehm's gc] package for mdk 10.1, so i downloaded and compiled it like this: <pre>./configure --prefix=/usr
make
su
make install</pre> (in fact i used <code>checkinstall</code> instead of <code>make install</code> and then <code>urpmi /usr/src[[/RPM/RPMS/i586/gc]]-6.4-1luc.i586.rpm</code>)
# <code>urpmi libxml2-devel</code>
# <code>urpmi libxslt-devel</code>
# <code>urpmi libsigc++2.0_0-devel</code> (to be found at urpmi source "contrib")
# <code>urpmi libgtkmm2.4_1-devel</code> (also urpmi source "contrib")
# <code>urpmi popt-devel</code> (urpmi source "main")
# finally you can perform successfully: <code>rpm -rebuild inkscape-0.41-1.src.rpm</code> (the resulting RPM package will be probably stored as <code>/usr/src/RPM/RPMS/i586/inkscape-0.41-1.i586.rpm</code> according to your RPM settings)

''luci''

Update by Chris Hill ubergeek at ubergeek dawt tv

I had some success with this method, but a couple issues:
The RPM would die on build because of an 'unpacked file'. So I ended up adding this to the spec file in /usr/src/RPM/SPECS

<code>%define _unpackaged_files_terminate_build 0</code>

I had other dependencies that I could not resolve easily:

<code>
libgc.so.1 is needed by inkscape-0.42-0

perl(XML::XQL) is needed by inkscape-0.42-0

perl(XML::XQL::DOM) is needed by inkscape-0.42-0

</code>
And I had indeed installed libgc, so I ended up installing with nodeps:

rpm -ivh --nodeps inkscape-0.42-0.i586.rpm 

Seems to be working fine (its so fast!!), but I might be missing perl/python support.

The HTML needs to be removed.
[[Category:Developer Documentation]]
[[Category:Needs Work]]

PresentationInkscapeOverview

2012-12-26T14:55:20Z

Romain2Boss: /* Inkscape: Open Source Scalable Vector Graphics Editor */ Links

== Inkscape: Open Source Scalable Vector Graphics Editor ==

* PUT YOUR NAME HERE
* PUT YOUR AFFILIATION HERE

Inkscape is an open source SVG editor with capabilities similar to Illustrator, [[CorelDraw]], Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more.

Inkscape's main motivation is to provide the Open Source community with a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned 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 establishment of a friendly, open, community-oriented development processes.

In this presentation, Inkscape will be presented and the community development process discussed.

=== Introduction ===
* Scalable Vector Graphics Editor -- Cross-Platform, Open Source, C++ codebase
* Started in November of 2003 from the [[SodiPodi/Gill]] codebase with 4 devs.
* Already grown to 10-20 developers by Spring 2004 & still growing
* This talk is going to be a technical introduction to the project.

=== Scalable Vector Graphics (SVG) ===
* Like HTML, but for graphics. XML standard for vector graphics
* Can write in a text editor using a straightforward & obvious syntax
* Vector vs. Raster
** Raster is an array of dots that "appear" to be shapes
*** Pro: With sufficient resolution can be photo-realistic
*** Con: Takes up lots of space even for simple geometric representations
*** Con: Difficult to split into component pieces for further editing
** Vector is real 2D shapes
*** Pro: Geometric representations scalable to any resolution
*** Pro: Easy to edit component pieces
*** Con: Difficult to do photo-realistic images at small file sizes

=== Cross-Platform & Open Source ===
* Platforms include Linux/[[UNIX]], Mac OS X, Win32
* Open Source means:
** The source code is available for free to the whole world
** The development process is open to all to participate in and enjoy

=== Uses of Inkscape ===
* Vector Art
* Symbology - Logos, Flags, Street Signs
* Webpage Graphics, Buttons, and Flourishes
* Visually Attractive Maps, Diagrams, and Technical Drawings

=== Development Community/[[Process]] ===
* This is a collaborative open source program involving around 10-20 developers from all over the world.
* It uses the standard open source development process with some smoothed out concepts to make it even more effective.
* Patch first, discuss later
* low barrier for developer commit access to CVS
* uses sourceforge.net
* Uses Network of Social Software (the key to distributive writing/dev)
** Website
** CVS
** Wiki
** Mailing List(s) and E-mail
** Chat (jabber.org)
* Bus Factor of the project (It has a high one)
* more?

=== Why is this important? ===
* In order to define this, one must decide to which community this is important.
* A production ready software does not exist in the GNU/[[Linux]] world.
** As you all would be concerned, this type of tool doesn't exist!
* Art Community
** It is free.
** It is high quality and production ready!
** Supports positive ideals!
*** Copyright is what it is, but we would like to see more opened up tools and codebases. Promotes development and honesty.
* Scientific Community
* Visualization Community

=== Common Misconceptions (Low Hanging Fruit) ===
* Isn't this just an open source Illustrator?
* Isn't there X, Y, and Z projects that already do this?
* Open Source doesn't innovate, it only imitates

=== Problems to be solved ===
* Not enough viewers
** solution: mozilla is pushing it
** solution: inkview
** solution: adobe svg is pushing hard!!!
* Our program is not fully compliant yet
** solution: need more developers and more integration

=== Future ===
* extension system
** quicker development
** don't have to know as much about the internals
* networked editing (shared space)
* layers
* clipart.freedesktop.org

----

=== Also Check the [[TufteStylePresentation]] ===

GeneralConferenceAbstract

2012-12-26T14:54:53Z

Romain2Boss: /* Overview of Inkscape, a Cross-Platform Open Source Scalable Vector Graphics Drawing Tool */ Links

== Overview of Inkscape, a Cross-Platform Open Source Scalable Vector Graphics Drawing Tool ==

Inkscape is a cross-platform open source Scalable Vector Graphics (SVG) drawing tool with capabilities similar to Illustrator, [[CorelDraw]], Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more.

Inkscape's main motivation is to provide the Open Source community with a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned 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 establishment of a friendly, open, community-oriented development processes.

In this presentation, Inkscape will be presented and the community development process discussed.

PressRelease041

2012-12-26T14:54:33Z

Romain2Boss: /* About Inkscape */ Links

subject line for email: Announcing Inkscape 0.41 Release . www.inkscape.org

= Inkscape Announces 0.41 Release . www.inkscape.org =

February 10, 2004 — The Inkscape community today announced the release of Inkscape 0.41, "A Cross-platform Open Source Vector Graphics (SVG) Drawing Tool."

Inkscape 0.41 focused on bug fixing. With over 100 bugs fixed since the 0.40 release, this significantly strengthened Inkscape on Windows and support for international users. With the help of countless users, Inkscape developers fixed several serious crashes, memory leaks and mis-features. The program is now noticeably snappier due to many user submitted bug reports.

Inkscape 0.41 also adds two extremely powerful features. First, the black and white tracing functionality introduced in 0.40 has been improved to also allow conversion of color and grayscale images into vector graphics. Now Inkscape can convert photos, scanned artwork, and other drawn images into editable illustrations in the SVG format. Second, is the addition of a new clone tiler facility which creates patterns, tessellations, and other sorts of geometric tiling arrangements. This aids in the creation of a plethora of patterns and textures through an easy-to-use dialog.

User requests and comments also stimulated a number of improvements to units handling, extensions, the Invert Selection command, layers selector, icon theming, and the addition of several new translations.

A number of large scale changes are planned for the 0.42 release, including converting the user interface to use Gtkmm behind the scenes and the incorporation of a new Document Object Model (DOM) which will provide the core for implementing scripting. The Inkscape community will be busy implementing these changes for the next couple of months and they encourage people to submit bug reports, feature requests, and to contribute code. For more information and to download Inkscape 0.41, visit www.inkscape.org. Draw Freely.

=== About Inkscape ===

Inkscape is an open source drawing tool that uses the [[W3C]] standard 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 meta-data, node-editing, layers, complex path operations, text-on-path, and SVG XML editing. It also imports several formats like EPS, Postscript, JPEG, PNG, BMP, and TIFF and exports PNG as well as multiple vector-based formats.

Inkscape's main motivation is to provide the Open Source community with a fully [[W3C]] compliant XML, SVG, and CSS2 drawing tool. Additional planned 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 the establishment of a friendly, open, community-oriented development processes.

[[Category:Marketing]]

ScriptingLanguages

2012-12-26T14:53:31Z

Romain2Boss: Links

I believe that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. This would be a great shortcut to accessing the SVG structure for non XML geeks ;)
--[[User:Xpressivo|Xpressivo]] 15:55, 2 July 2006 (PDT)

----

Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.

Scripting allows many more developers to contribute, and allows new ideas to be prototyped essentially on the spot.

I think the core scripting interface should be relatively simple and language-neutral, like [[The_Gimp]]'s PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.

Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C/C++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.

Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

----

Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.

Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...

-- [[User:MenTaLguY|MenTaLguY]]

----

I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in [[ModuleFormat]].

----

Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.

Of course, some decisions need to be made as to what to potentially support. This would apply to potential scripting languages and to potential features. Think of both the tasks to accomplish and of the languages to accomplish them in.

For an example of the tasks/concepts, we could think of a raster paint program (like [[The Gimp]] or [[PhotoShop]]). These deal with raster images. Additionally, it's nice to be able to work on images with different numbers of channels, different bit-depths and different colorspaces. The [[PhotoShop]]
plugin API has supported all of this for years. Sadly, [[The Gimp]] did not at the begining. Thus problems with working in CMYK or in bit depths neede for Hollywood work both have been problematic for [[The Gimp]] and its plugins.

Blocking future functionality, I think, is the main thing that Inkscape needs to avoid. As [[MenTaLguY]] has said, it's best if plugins were first-class citizens. So what needs to be exposed?

Things off the top of my head:

<pre>
-Document
|-XML / parse tree
|-view tree

-UI Thingies / dialogs / user interaction

-Utility calls / factories
</pre>

-- [[User:JonCruz|JonCruz]]

----

More than one language to write extensions can help the development.

The [http://www.mozilla.org/js/spidermonkey/ [[SpiderMonkey]]] is a great javascript engine, used by Mozilla web browser, and implements the [http://www.mozilla.org/js/language/js20/ [[JavaScript]] 2.0] specification.

[[JavaScript]] is a easy language and is the defined language to animate SVG. With the powerfull 2.0 version we can do good extensions to Inkscape.

The [[AST]] is a great idea to manipulate the SVG, but may we access in the same DOM used to [[DHTML]]. And it will be natural to DHTML scripters and developers.

It's written in C, is fast and low weight. I'm waiting to write new effects to Inkscape with my prefered language! :-)

-- [[User:AurelioAHeckert|AurelioAHeckert]]

SubsystemRearchitecture

2012-12-26T14:52:45Z

Romain2Boss: /* Subsystems Summary */ Links

{{outdated}}
{{DevDiscussion}}
== Subsystems Summary ==

Namespace Link Audience Lib Name Directory
Inkscape::Document C++ Internal libinkdoc src/document
Inkscape::Extension C++ Internal libinkext src/extension
Inkscape::SVG::Object C++ Internal libinksvgobj src/svg/object/
Inkscape::UI C++ Internal libinkui src/ui/
Inkscape::UI::Dialogs C++ Internal libinkuidlg src/ui/dialogs
Inkscape::UI::Widgets C++ Internal libinkuiwdg src/ui/widgets
SVG::Canvas C/C++ Community libsvgcanvas src/svgcanvas
SVG::DOM C/C++ Community libsvgdom src/svgdom

Cairo C (dep) libcairo (external)
Pango C (dep) libpango (external)

== Descriptions of Proposed Subsystems ==

Inkscape::Document - This is a high level wrapper for the application's
document model, and basically just subclasses SVG::DOM, adding some
Inkscape-specific aspects.

Inkscape::Extension - This namespace encapsulates the various mechanisms
for extending the Inkscape application, including import/export
mechanisms, GUI plugins, stdin/stdout programs, language bindings, etc.

Inkscape::SVG::Object - This will include SPObject and its children

Inkscape::UI - Namespace for Inkscape-specific User Interface elements,
including view & controller aspects.

Inkscape::UI::Dialogs - dialogs for Inkscape

Inkscape::UI::Widgets - widgets that are particular to Inkscape; if they
seem to be of general use, they will be migrated into a separate library
to share with other applications in a more general fashion.

SVG::Canvas - A distinct deliverable Inkscape provides to the Open
Source community for implementing an SVG-based drawing surface, for use
in other applications. Initially will be made up of similar subsystems
shared with Inkscape but be a separate package, but ultimately should be
a packaged dependency of Inkscape.

SVG::DOM - This is a Document Object Model for SVG documents. It is the
key dependency for SVG::Canvas, and thus is also something Inkscape
provides externally to the Open Source community. Internally, it is
implemented as a C++ class hierarchy, but externally can be linked to
using either C or C++ style linkage. The externally presented API would
be standard DOM.

Cairo - Switching to Cairo will occur late in the rearchitecturing
process. We need to ensure Cairo provides the capabilities already
present in libnr. Completing other areas of rearchitecting will help
get the codebase organized for conversion of it to Cairo, without
taking undue risk in adopting a different underlying renderer.

Pango - Conversion to Pango from libnrtype may be worth doing earlier
than Cairo since the existing text system lacks many needed features,
however this will need to be researched in more depth to determine the
feasibility and cost/benefit. Unless a clear benefit is identified to
performing the change early, we should conduct the change along with the
Cairoification.

== Rearchitecturing Translation Map ==

This shows how items in the [http://www.inkscape.org/doc/devdocs.php current block diagram] would be
converted into the new subsystem architecture.

Existing Proposed
GUI
Dialogs --> Inkscape::UI::Dialogs
Widgets --> Inkscape::UI::Widgets, [[GtkDrawmm]]
XML Editor --> Inkscape::UI::Dialogs
View --> Inkscape::UI
SPAction --> Inkscape::UI
verbs --> Inkscape::UI
shortcuts --> Inkscape::UI
SVG DOM --> Inkscape::Document, libsvgdom
SVG Canvas --> libsvgcanvas
Module --> Inkscape::Module
Display --> Cairo
libnr --> Cairo
libnrtype --> Pango
SPSVGView --> SVG::Canvas
[[SPSVGViewWidget]] --> SVG::Canvas
src/svg/* --> eliminate
SPObject --> Inkscape::SVG::Object (and to /src/svg/object/)

SPRepr -> Inkscape::XML::Node
[[SPReprDoc]] -> Inkscape::XML::Document
[[SPReprAttr]] -> Inkscape::XML::[[AttributeRecord]]
[[SPReprAction]] -> Inkscape::XML::Event
[[SPReprEventVector]] -> Inkscape::XML::[[NodeEventVector]]

Category:Dialogs

2012-12-26T14:41:14Z

Romain2Boss: Created page with "Category:User Documentation"

[[Category:User Documentation]]

Category:Widgets

2012-12-26T14:41:04Z

Romain2Boss: Created page with "Category:User Documentation"

[[Category:User Documentation]]

CurrentColorWidget

2012-12-26T14:37:39Z

Romain2Boss:

As a first step towards color palette, each document window needs a current color widget. It may be placed e.g. in the bottom left corner instead of the "scale when resizing window" button which is to be removed (this must be a global setting in [[PreferencesDialog]]). Here's what we need to do:

* The widget itself is just two small concentric rectangles; the inner displays fill color, the outer, stroke color. If there is transparency, a checkered background should show through. It must also display gradients and other fill types. (can we use a small arena for this, with the actual SVG template rendered with the current style?)

* The widget reflects the current color of the fill and stroke, which are properties local to SPDesktop. It is stored as RGBA values (displaying patterns and gradients may be added later). The widget responds to the [[SetColorSignal]] to change its displayed color.

* Click on the current color widget must bring up the fill&stroke dialog with fill tab. Shift+click must show the stroke tab.

Also each desktop must store the current stroke style (or only width?). Show and make it selectable (drop-down) somewhere near the current color widget.

[[Category:Needs Work]]

SymbolsDialog

2012-12-26T14:33:42Z

Romain2Boss: Add Dialogs Category

=Symbols Dialog=

== Features ==

Allows copying and pasting symbols (<symbol> elements) from both the document being edited and from symbol libraries.

== Use ==

* Open ''Symbol dialog'':
** Object -> Symbol dialog..., or
** Ctrl-Shift-Y. (Note, the shortcut was used for Edit->Undo. I am guessing that this shortcut is pretty unused.)

* Select symbol set

* Drag and drop symbol into document, or
* Copy and paste by
** Click on symbol to copy to clipboard
** Paste (Ctrl-V) to document.

== Symbol Libraries ==

Symbol libraries are sets of symbols located in one SVG document. Inkscape will look for libraries in the ''share/symbols'' directories (both system and personal). Any <symbol> elements defined in the <defs> section will be picked up. (<symbol> elements are allowed anywhere in an SVG document according to the spec, but Inkscape seems to have some trouble if they are not in the <defs> section.)

In order to allow styling of symbols from within Inkscape, styling should be kept out of <symbol> elements as much as possible. It is then possible for a symbol to inherit the styling of the <use> element that references it. In order to provide a default style to a <symbol> one can either provide a general default style in the root <svg> element of the library or add a symbol specific default style by putting a style string in the "inkscape:symbol-style" attribute inside the symbol element. When a symbol is selected in the Symbol dialog, the style will be added to the <use> element in the clipboard.

Note that as a symbol library is an ordinary SVG file, one can also include documentation and/or sample diagrams in the same file.

There are two sample sets of symbols, one with Logic symbols and with AIGA/DOT transportation symbols.

Visio stencil files (.vss) can also be used as a source of symbols by dropping the files into the ''share/symbols'' directory (if libvisio has been linked in).

== Editing Symbols ==

Two commands are available to allow editing of symbols from within Inkscape:

* '''Object->Symbol to Group''':

This converts the <symbol> referenced by the selected <use> element to a group located in the untransformed position of the symbol. The new group is left selected. Any <use> element (clone) that referenced the symbol should be left referencing the group. No default styling is applied to the group itself (since there is no <use> element to inherit it from).

* '''Object->Group to Symbol'''

This converts a selected group to a <symbol> element. No <use> element is created. Any <use> elements that referenced the group will now reference the symbol. The new symbol can be selected in the Symbol dialog in the ''Current Document'' Symbol set. (You may need to unselect and then reselect the ''Current Document'' set to get the symbol to show.)

A lot of alternative ways were tried to be able to round-trip symbols to groups and back. This method seemed the most straight forward and avoids issues with transforms and styling.

Copying (Ctrl-C) and then pasting a symbol, or duplicating a symbol creates a new <use> element (clone) referencing the same symbol.

To copy a <symbol> for creating a new <symbol>, first convert the symbol to a group, copy the group, edit the copied group, and convert both groups back to symbols (give the new group a useful "id" and "title" using the Object Properties dialog).

== Bugs/Issues ==

* Switching Desktop should switch Document Symbol set. (At the moment this is not an issue as each desktop gets its own Symbol dialog.)
* Symbol to Group/Group to Symbol should trigger an update to the symbols shown in the Symbol dialog when symbol set ''Current Document'' is selected.
* Editing a symbol should result in updating the image in the Symbol's dialog.
* Symbols have not been tested well inside Inkscape.
* Symbols referring to external elements (gradients, etc.) probably won't work.
* Symbols can have their own viewbox, this has not been tested.
* Inkscape gives the <use> element linking to a symbols a width and height of 1. This is incorrect and leads to rendering errors in other SVG renderers. Width and height (as well as x and y) should not be set unless explicitly given. This needs to be fixed. A work-around is to set overflow="visible" in a <symbol>.
* "GLib-CRITICAL **: g_strsplit: assertion `string != NULL' failed" error occur often.

== Future Enhancements ==

* Generic symbols: It should be possible to extend the Symbol dialog to include <g> elements as well as <symbol> elements. A group could be marked as a symbol by adding an "inkscape:symbol" tag. In this way one can put place holders in for things like text:

<pre>
<g role="inkscape:symbol">
<symbol id="wrapperBox">...</symbol>
<text id="label">...</text>
</g>
</pre>

* Connectors: Symbols beg for the use of connectors. It would be easy to define connection points inside a symbol. The Logic symbols include extra nodes to make snapping of input/output lines to the correct places easier. These nodes would be better defined as connection points. Work on an [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector] proposal is in progress.

[[Category:Dialogs]]

User Interface Modules

2012-12-26T14:33:06Z

Romain2Boss: /* Dialogs */ Add Symbols Dialog

Discussion and documentation about specific Inkscape dialogs, widgets, tools and more inside the [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/ src/ui] directory.

== Dialogs ==

By extension, a '''dialog''' in Inkscape vocabulary is any type of window, i.e. a set of widgets with an OS decoration, a title...

All dialogs are in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/dialog src/ui/dialog] (except for old dialogs).

* [[Class Inkscape::UI::Dialog::AboutBox]]: The ''About Inkscape'' dialog
* [[Class Inkscape::UI::Dialog::AlignAndDistribute]]: The ''Align and distribute'' dialog
* [[Class Inkscape::UI::Dialog::Behavior::Behavior]]
* [[Class Inkscape::UI::Dialog::Behavior::DockBehavior]]
* [[Class Inkscape::UI::Dialog::Behavior::FloatingBehavior]]
* [[Class Inkscape::UI::Dialog::CaligraphicProfileRename]]
* [[Close Dialog]]
* [[Class Inkscape::UI::Dialog::ColorItem]]
* [[Class Inkscape::UI::Dialog::DebugDialog]]
* [[Class Inkscape::UI::Dialog::DesktopTracker]]
* [[Class Inkscape::UI::Dialog::Dialog]]
* [[Class Inkscape::UI::Dialog::DialogManager]]
* [[Class Inkscape::UI::Dialog::DocumentMetadata]]: The ''Document metadatas'' dialog
** [[Andrews Big Dialog Re-Design/Document Metadata]]
* [[Class Inkscape::UI::Dialog::DocumentProperties]]: The ''Document properties'' dialog
* [[Class Inkscape::UI::Dialog::ExtensionEditor]]
* [[Class Inkscape::UI::Dialog::ExtensionPanel]]
* [[Export Bitmap Dialog]]
** [[Export Bitmap Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/Export Bitmap]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseGtk]]
* [[Class Inkscape::UI::Dialog::FileDialogBaseWin32]]
* [[Class Inkscape::UI::Dialog::FileDialogOCALBase]]
* [[Class Inkscape::UI::Dialog::FileImportFromOCALDialog]]
* [[Class Inkscape::UI::Dialog::FileListViewText]]
* [[Class Inkscape::UI::Dialog::FileOpenDialog]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileSaveDialog]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplGtk]]
* [[Class Inkscape::UI::Dialog::FileOpenDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileSaveDialogImplWin32]]
* [[Class Inkscape::UI::Dialog::FileExportDialog]]
* [[Class Inkscape::UI::Dialog::FileExportDialogImpl]]
* [[Stroke Dialog]]
** [[Fill and Stroke Dialog Re-Design]]
** [[Class Inkscape::UI::Dialog::FillAndStroke]]
* [[Class Inkscape::UI::Dialog::FilterEffectsDialog]]
* [[Class Inkscape::UI::Dialog::Find]]
* [[Class Inkscape::UI::Dialog::GlyphsPanel]]
* [[Class Inkscape::UI::Dialog::GuidelinePropertiesDialog]]
* [[Class Inkscape::UI::Dialog::IconPreviewPanel]]
* [[Image Properties Dialog]]
** [[Image properties dialog enhancements]]
* [[Class Inkscape::UI::Dialog::InkscapePreferences]]: The ''Inkscape preferences'' dialog
* [[Class Inkscape::UI::Dialog::InputDialog]]
* [[Layer Dialog]]
* [[Class Inkscape::UI::Dialog::LayerPropertiesDialog]]: The ''Layer properties'' dialog
* [[Class Inkscape::UI::Dialog::LayersPanel]]
* [[Class Inkscape::UI::Dialog::LivePathEffectEditor]]
* [[New Document Dialog]]
* [[Class Inkscape::UI::Dialog::Memory]]
* [[Class Inkscape::UI::Dialog::Messages]]
* [[OCAL Dialog]]
** [[OCAL Dialog Re-Design]]
** [[Andrews Big Dialog Re-Design/OCAL]]
* [[Class Inkscape::UI::Dialog::PanelDialogBase]]
* [[Class Inkscape::UI::Dialog::Print]]: The ''Print...'' dialog
* [[Class Inkscape::UI::Dialog::PrintColorsPreviewDialog]]
* [[Class Inkscape::UI::Dialog::ScriptDialog]]
* [[Class Inkscape::UI::Dialog::SvgFontsDialog]]
* [[Class Inkscape::UI::Dialog::SVGPreview]]
* [[Class Inkscape::UI::Dialog::SwatchesPanel]]
* [[SymbolsDialog|Symbols Dialog]]
* [[Tablet Dialog]]
* [[Text Dialog]]
* [[Class Inkscape::UI::Dialog::TileDialog]]
* [[Class Inkscape::UI::Dialog::TraceDialog]]
** [[Trace Bitmap Dialog Re-Design]]
* [[Class Inkscape::UI::Dialog::Transformation]]
* [[Class Inkscape::UI::Dialog::UndoHistory]]: The ''Undo history'' dialog

Dialogs that have not yet been rewritted can be found in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/dialogs src/dialogs].

=== Others re-designs ===

* [[Andrews Big Dialog Re-Design]]
* [[Andrews Big Dialog Re-Design/Embed or Link]]
* [[FindReplaceDialog]]
* [[DialogsReorganization]]

== Widgets ==

Widgets are implemented in [http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head%3A/src/ui/widget src/ui/widget].

* [[Class Inkscape::UI::Widget::ColorPreview]]: A simple color preview widget, mainly used within a picker button
* [[Class Inkscape::UI::Widget::ProgressPannel]]
* [[Class Inkscape::UI::Widget::SpinButton]]: Widget that allows entry of simple math expressions (also units, when linked with UnitMenu), and allows entry of both '.' and ',' for the decimal, even when in numeric mode
* [[Class Inkscape::UI::Widget::SpinSlider]]: Groups an Gtk::HScale and a Inkscape::UI::Widget::SpinButton together using the same Adjustment
* ...

Also a proposal for a [[Color Entry Widget|Color Entry]].

== src/ui/tools ==
* ...

== Toolbars ==

A '''toolbar''' is a set of graphical widgets put around the canvas to provide actions on objects, canvas or documents.

See [[Toolbar]] page for more informations.

== Menu ==

See [[Menu]].

[[Category:Developer Documentation]]

Text Dialog

2012-12-26T14:31:06Z

Romain2Boss: Add Dialogs Category

<table style="width: 100%;">
<tr>
<td style="text-align: center; font-weight: bold;">GIMP</td>
<td>upload:text_gimp.png</td>
</tr>
<tr>
<td style="text-align: center; font-weight: bold;">Inkscape</td>
<td>upload:text_inkscape.png</td>
</tr>
<tr>
<td style="text-align: center; font-weight: bold;">Scribus</td>
<td>upload:text_scribus.png</td>
</tr>
</table>

Andreas: Right now, only Scribus lets the user interact directly with the text. I belive a more direct text behavior is planned for Inkscape.

[[Category:Dialogs]]

Tablet Dialog

2012-12-26T14:30:54Z

Romain2Boss: Add Dialogs Category

== Mock Up ==
More will come here soon, but I've got a rough half mock up of what the new dialog might look like:

[[Image:Tablet_dialog_new.png]]

== Current State ==

Here is a snapshot of the progress on it as of March 9th. I'm planning on splitting between the hardware itself, and the configuration. The hardware tab will reflect the items actually attached to the computer, and the Configuration tab will have things like Screen/Window mode, key bindings, etc.

[[Image:Dialog_progress.png]]

Splitting those up should allow for the hardware to be set once, and then many different configurations set up for that one hardware set. The hardware tab will let me set the *real* number of buttons per device, since it appears that the drivers list a few more than are always there. Also this will be where to mark an eraser device as matching a stylus device to make up a single physical device.

[[Category:Dialogs]]

New Document Dialog

2012-12-26T14:30:41Z

Romain2Boss: Add Dialogs Category

Layer Dialog

2012-12-26T14:30:28Z

Romain2Boss: Add Dialogs Category

== Using the Layers dialog ==

The Layers dialog controls all layer functions: adding new layers, renaming, deleting, arranging, toggling visibility and edit-locking and setting Blend mode and opacity.

[[File:Layer_Dialog.png|200px|thumb|left]]

The Layers dialog can be opened by going to <tt>Layer > Layers...</tt>.

Most of the Layer functions are already available in this menu, including:
*add, duplicate, rename
*view one layer up/down
*move selection to layer up/down
*changing order of layers
*delete layer

There is also a <tt>View Layers</tt> shortcut button on the Commands Bar toolbar.

== Work in progress ==

== Suggestions for improvements ==

=== Adobe Illustrator sublayers ===
It would be good to consider using sublayers like in Illustartor: http://upload.wikimedia.org/wikipedia/en/8/88/Adobe_illustrator_10.png --Host-216-229-237-115.public.southern.edu 15:27, 3 October 2005

=== drag&drop functionality with opened Layer Dialog ===
simply make a selection, open the layer dialog, drag the desired Layer on the selection and drop -> the selection is added to the desired Layer--[[User:Touringlonewulf|Touringlonewulf]] 11:28, 23 August 2010 (UTC)

=== additional item in Layers menu ===
under "move selection up/down" the point: "move selection to layer" -> a new drop down opens, which shows all layers and another point "create new". Now simply clicking in the drop down list on one layer will move the selection to that layer--[[User:Touringlonewulf|Touringlonewulf]] 11:28, 23 August 2010 (UTC)

=== additional button in Layer Dialog Box ===
"import bitmap/svg into current layer"

== See also ==

*[[DocumentLayers]]
* [http://en.flossmanuals.net/Inkscape/Layers Floss Manuals User guide article on Layers in 0.47]

[[Category:Dialogs]]

Stroke Dialog

2012-12-26T14:30:12Z

Romain2Boss: Code cleanup and add Dialogs Category

<table style="width: 100%;">
<tr>
<td style="text-align: center; font-weight: bold;">GIMP</td>
<td style="text-align: center; font-weight: bold;">Inkscape</td>
<td style="text-align: center; font-weight: bold;">Scribus</td>
</tr>
<tr>
<td>upload:stroke_gimp.png</td>
<td style="text-align: center;">[[Image:stroke_inkscape.png]]</td>
<td>upload:stroke_scribus.png</td>
</tr>
</table>

The Inkscape stroke dialog is what I prefer to call a '''Palette''' and it is intened to be always left open and is deliberately compact.

The GIMP uses a transient dialog which is quite different and follows the GNOME HIG rules for layout of that kind of dialog. This is a perfectly valid approach and for GIMP users. I dont think the stroke options are so important that they need a palette always open taking up space onscreen.

It begs the question does inkscape need a Palette rather than a standard transient dialog?

[[Category:Dialogs]]

Close Dialog

2012-12-26T14:28:30Z

Romain2Boss: Add Dialogs Category

<table style="width: 100%;">
<tr>
<td style="text-align: center; font-weight: bold;">GIMP</td>
<td style="text-align: center; font-weight: bold;">Inkscape</td>
<td style="text-align: center; font-weight: bold;">Scribus</td>
</tr>
<tr>
<td>upload:closeimage_gimp.png</td>
<td>upload:closeimage_inkscape.png</td>
<td>upload:closeimage_scribus.png</td>
</tr>
</table>


The Close dialog used in Inkscape is closest to what is specified in the Gnome Human Interface Guidelines.
There has been some discussion on the Gnome list about trying to create a standard Close Dialog to try and get rid of this inconsistency that effects the whole of Gnome.


Might be of interest: [http://live.gnome.org/UsabilityTeam_2fSaveConfirmationDialogs HIG compliance] (that page is really quite hard to read)

[[Category:Developer Discussion]]
[[Category:Needs Work]]
[[Category:Dialogs]]

Color Entry Widget

2012-12-26T14:21:28Z

Romain2Boss: Add Summary and Prepare SVG2

Here are the aims of this blueprint.

== Deal with full SVG 1.1 colors ==

The entry accepts colors as defined by the [http://www.w3.org/TR/SVG/color.html SVG 1.1 Specifications].

SVG 1.1 colors do not handle alpha (it's stored in a separate attribute). We have three options:

# Change nothing and keep displaying the alpha value with the color value by extanding the SVG specification (#RRGGBB => RRGGBBAA, rgb(255, 255, 255) => rgba(255, 255, 255, alpha)...).
# Do like many softwares and display the color in the entry without the alpha (which is displayed in it's own entry). This would probably need a widget rearrangement.
# Allow both: implement the SVG 1.1 specification (case 2) and keep case 1 as a preparation for SVG 2. This will allow inputs but, because Inkscape files are SVG 1.1, any loaded file will be displayed using case 2.

The third case is proposed.

== Prepare SVG 2 ==

Based on [http://www.w3.org/TR/SVG2/color.html SVG2]. The idea is to be more ''SVG 2 ready''.

=== sRGB colors ===

The HSL format is closed to RGB: no issue.

Some color named are added: no issue.

=== sRGB colors with alpha ===

RGBA and HSLA are added: no issue.

=== ICC and LAB colors ===

To be implemented?

== Keep the user value ==

Colors are stored in the SVG file as specified by the user (i.e. no more forced conversions to hex values). However, for internal purposes, the colors can be stored and handled differently. This would mean having an internal color value (as now) and a display value.

The color sets in the entry is (chronologically):

# First, the color as written in the SVG file (if any)
# Then, if modified by the user (pasted or typed), the user value
# Then, if modified by the software (in case of multiple input widgets), the software value

If the alpha is not part of the user input, Inkscape keep the previous one and will not append it in the entry.

== Help the user ==

If the text in the entry cannot be converted to a valid color, the entry changes it's appearance (red border?).

If a color from the palette is dragged and dropped on the entry, it takes the color value.

[[Category:Proposals]]
[[Category:Widgets]]