I hope you don't mind if I increase the traffic on inkscape-devel even
At some point an idea popped up to only snap to nodes at discontinuities
in paths, and not to nodes at smooth transitions from one Bézier segment
to another. This is more intuitive (less "Hey, what it is Inkscape
snapping to now?") and might increase performance.
Problem is that in the object-snapper I only have access to SPCurve,
which is a wrapper for "old-style" NArtBpath. It's easy to find out
whether a point is inbetween two Bézier segments, but how do I find out
if a transition is smooth? I guess that should be done by comparing the
control points, or is there an easier way? With the transition to
lib2geom, will the NArtBpath be deprecated in favor of the Path class?
(that would make this rather exercise useless in the long run).
Any pointers would be appreciated here,
Sorry for posting here if the user list if better. And sorry about the
subject if it has been talked about before. I couldn't get sourceforge
to add me to the inkscape user mail list and sourceforge was timing out
on all my archive searches with no results.
I remember reading that there was a patch or something to inkscape to
support wishblade and robocraft users. Has that been integrated into
the inkscape application? Is that what the DXF is all about?
Wishblade users can not use DXF directly (needing the robocraft software
to import DXF and change it to some sort of native (and maybe
proprietary) GSD). Is there a way to get inkscape to save images in GSD
in order to simplify the process?
Ideally, I would prefer to skip bringing up the wishblade application.
In my set up, I do all my work in linux (GIMP/INKSCAPE) and only the
plotting in Windows. If I could do everything in linux it would
simplify the flow of work greatly. Has anyone figured out how the
craftrobo is communicated to in order to use it with common open source
linux plotting software?
Better yet, has anyone figured out how the wishblade has been crippled
in order to use it with common open source linux plotting software?
I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this.
sorry if this is a dumb question but how can I change my Launchpad
settings so that I do not receive an email each time someone works on
one of the bugs? Is this the default behaviour for members of the
"Inkscape Bug Team" group? Currently I am sent a notification for each
and every change, but I'd prefer not to get my inbox flooded and rather
browse the list myself when appropriate. It may be just my infamiliarity
with Lauchpad (and lack of time for detailed investigation), but I
wasn't able to find out how turn this off. Thanks in advance.
I just uploaded a new lib bundle on the server.
It has been over a year since I last updated the C++ libs.
I also have wanted for months to move from the existing
setjump/longjump (sjlj) exception handling to the new
(to MinGW) Dwarf2 EH. Gcc has had Dwarf2 for years, but
only recently has MinGW started providing it. It should
allow better backtraces and slightly smaller binaries.
I made a build with it manually this morning:
I assembled some MinGW binaries to make this working compiler:
...and here is the new bundle.
Note that the C++ compiler, library bundle, and Inkscape build
must all be either sjlj or Dwarf2. You can't mix them, else
there will be a linking error.
I also added a version of build.xml to the trunk to handle this,
build-dw2.xml. This should keep from breaking everyone else's
build. To use it:
./btool -f build-dw2.xml
Of course there is a corresponding cross-compiler:
...which made this build, which looks ok, but I haven't run yet:
It looks larger, but none of the DLLs have been stripped yet.
From now on, all of the "autobuilds" there will be Dwarf2.
Probably in a couple of weeks when everyone catches up, it will become
Here are several more notes on current implementation of raster effects.
1. Terminology and hints. In some cases terminology used in effects
coming from ImageMagick is not quite obvious. For instance, you might
want to reread a course on math to understand what "Sigma" stands for
in "Sharpen"/"Unsharp Mask" effects ;-) We might either rename some of
the labels (not good for experienced ImageMagick users) or provide
hints to explain the meaning of each option.
2. Raster effects are not the only ones to suffer from it, but here
goes: effect dialogs inherit caption from menu item name. In several
cases the caption is too long and is shrinked. This is not quite
visually appealing. Two solutions comes to mind: 1) automatically
resize dialog to match caption's length and 2) provide a separate
string to dialog's caption which translators could try to make
3. Cancelling isn't working reliably. I run "Reduce noise" on a
2200x1500 picture and when I click "Cancel" nothing really happens.
4.Should we probbaly implement a "Resize" effect too?
I just committed a change to SVN (rev. #17022) which allows the user to
convert rectangles and 3D boxes to a collection of guidelines that are
aligned along these objects' edges.
Originally, this was a stab at something in the direction of RFE #172136
(in particular, it was only meant to work for 3D boxes). But since I'm
not familiar yet with grid infrastructure I thought that instead of a
grid it would be easier to create a couple of guidelines from a box,
which can then be used as a basis for 3D based drawings. Not as
functional as a 3D box based grid but better than nothing.
Then it occurred to me that it may be even more useful to convert
*rectangles* to guides because in this way it becomes much easier to
create guidelines in specified positions/constellations (imagine
applying it to rotated or skewed rectangles). So I implemented this as
well and added an additional menu entry "Object->Objects to guides"
which allows conversion to guidlines of any rects or 3D boxes in the
Now I have some questions.
1) I'm not sure if this kind of change should occur during Frost phase
(I couldn't ask for an exception before because I hadn't thought of it
at that time). But since IMHO it's an extremely useful yet very
lightweight change - even if a couple of files were adapted - and I
don't see any way in which this can possibly break things, I committed
it anyway. If it is not desired and should be held back until after
0.46, please feel free to revert it.
2) Originally I added a button to the 3D box toolbar which allowed
conversion of selected boxes to guides. After providing this option for
rects, I also added this button to the rect toolbar, but then I thought
it might also make sense in (at least) Selector tool, so I decided not
to clutter the toolbars and removed the buttons altogether in favor of
the menu entry. Do you think there is any value for such buttons?
3) I added the keyboard shortcut 'Shift+G' for conversion to guides in
Rect, 3D Box and Selector tools. Do you think this is appropriate (I
personally find it very handy to have a quickly accessible shortcut in
these tools) or should there rather be a global shortcut associated with
the corresponding verb? What would be an appropriate one?
P.S.: Release Notes will be updated in case this change is accepted for
0.46. BTW, I'm aware that I still need to update them for the 3D box
tool and other things. Will do so as soon as possible.
On 2008-January-31 , at 00:45 , carl olsen wrote:
> I'm very interested in contributing to the project. I have
> intermediate programing experience, but need someone to mentor me. I
> pick this stuff up pretty fast so I just need to get in touch with
> someone who knows about developing on os x and can tell me what to
> work on.
That's great news!
If you are looking into developing the OS X side of Inkscape
(integration with the OS, appearance, building with native GTK), it
has been my area of focus for a while. I don't have much time right
now but know what needs to be done and where to look.
If you are interested in developing Inkscape in more general sense and
that OS X just happens to be your platform of choice, there are at
least two people you can contact: Jon Cruz (jon at joncruz.org) and
Michael Wybrow (michael.wybrow at infotech.monash.edu.au). They have
been silent for a little while though, so you may need to be patient
to get an answer.
However, developing on OS X is quite straightforward and very similar
to the process on Linux (we don't use XCode or any other OS X specific
environment, so you only need a text editor, a terminal, gcc and
make). Once you get Inkscape to compile as per these instructions:
you're ready to go (I advise you to remove the option --enable-osxapp
at configure time and just keep Inkscape as a plain command line app,
which is easier to debug and run with special options).
Then, to know more about Inkscape internals, development practices or
what's on the wish list, subscribe to the devel mailing list and hang
out on the IRC channel, you'll find plenty of clever people there.
It's release time right now so focus is on bug fixes and major
development has to happen in branches. You can use a SVN branch or use
git locally (via git-svn) and prepare your patches with it. The "rule"
is that, once you get two solid patches accepted, you are given direct
Thanks for offering your help!
PS: I'm ccing you and the devel list so that people hav your address
if they want to reply directly. However you should really subscribe to
the devel list afterwards.
Correct me if I'm wrong, but skimming the roadmap I was unable to find any
reference to work on a swatch palette for named colors, grdients and patterns.
I'm talking about a single dialog where the user can create named colors which
would later be referenced by name in the XML (I don't know if SVG allows it) -
for example, suppose I create buttons and other graphic elements for a website
design. I have many of them and they are differently shaped. I might want to
paint them with a blue color. I then create a new swatch, name it
"buttonBackground" and set all the background rectangles to use it. Later, I may
want to change the entire color scheme of the website - in this case all I need
to do is just access that swatch and change its value to, say, red - and all The
button backgrounds immediately update.
I feel this is a very basic, important feature missing from Inkscape. I know
from experience I use this extensively on other applications, and even on
Inkscape I try to fake this feature by creating gradients with two identical
colors and sharing them between shapes (but it's awkward and the gradients can't
be named and are hard to find among the long list of used gradients in a large
Hi guys, overall you did a terrific job on these features, but I have
several comments/questions on the UI:
- "snap guides while dragging" option does not seem to work - no
snapping to grid, other guides or objects
- can we disable the remove button when there's nothing to remove in Grids?
- can we give grid names that at least reflect their type, e.g.
AxGrid2222 or RectGrid2222 instead of grid2222?
- why two checkboxes, "enabled" and "visible"? what's the difference?
It's not clear. I propose to rename them to "Snapping enabled" and
"Grid visible". Also if I uncheck "enabled", visible does not work -
why? if that's intentional, please just gray out the rest of the grid
options when "enabled" is unchecked.
- why there's no option for hex grid to show dots?
- Snap tab: for what snaps/nodes, the tooltip lists what they may snap
to, but here, more important is another question - what are nodes?
only path nodes, or special points in shapes? what about gradient
handles and text baselines - are they "nodes" too? I think this needs
to be clarified right here. What they snap to is clear from the rest
of options below.
- same about what snaps/bboxes: what they snap _to_ is not important
here, it's clear from the rest of options anyway, but that it only
works in selector is important.
Oops, no, wait; I just noticed that bboxes don't snap to paths/nodes,
and nodes don't snap to bboxes. In that case this should be mentioned
in the tooltips of course (e.g. "snap to bounding boxes of other
objects but not to their paths" and vice versa).
- "Snap at specified distance" is misleading; better something like
"Snaps only when closer than:"
- "Miscellaneous" is a bad label - doesn't this option belong in "what
snaps"? Maybe as a suboption under "nodes" - am I right in assuming
the rotation center is considered a "node" for snapping?
- in any case, "Also snap the rotation center of an object when
snapping nodes or guides" - why are guides mentioned here? how can I
snap rotation center of a guide?
- finally, I think we should rearrange the tabs again :) Tooltips that
include "see previous tab" are a sign that something is very awkward
here. As I understand the options, I would propose dividing them as
first tab: "Snapping"
- enable snapping
- what snaps, including the rotation center option
second tab: "Snap targets"
- snap to guides
- snap to grids
- snap to objects
- snap to intersections
(in this order!)
What do you think?
Inkscape. Draw Freely.