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.
One other glitch which the tweak tool revealed: undoing looses
draw a circle, switch to tweak, tweak, CTRL-Z, tweak again = you
can't because the circle is not selected anymore.
draw a circle, draw another, select all, switch to tweak, tweak
circle nb 1, CTRL-Z, switch to select = only circle nb 2 is selected
In fact this happens in all tools:
draw a circle [-> it is selected], draw another [-> the second one
gets selected], CTRL-Z = nothing is selected anymore
This is not particularly annoying in all other tools but it is in the
tweak tool, because undoing the first tweak deselects and an
additional tool switch is necessary before one can tweak again. I
already noticed that when the too was in its embryonic stage in the
calligraphy tool... but failed to report it :(
It would be nice if:
- the selection could be kept in Undo history. this would solve the
issue for all tools and in addition I found myself bitten by the lack
of selection history several times. Ex: you try to select several
small objects, it takes a while, you add another object by mistake,
the only way to subtract it from the selection is to click on it
again... which cool get messy if there are already several other
objects selected, or if you added it via a select under or in group
- there was a way to select objects directly from the tweak tool.
this would, in addition, allow to avoid constant switches between the
select tool and the tweak tool (not that s and and w are far apart on
the keyboard but still). ALT is not already used as a modifier in the
Tweak tool ;) Of course the selection behavior won't be as powerful
as the select tool (since the select tool modifiers is already very
complex and its modifiers are all full) but just ALT+click/drag =
selects and SHIFT+ALT+click/drag = adds to selection would be nice.
>> is there any way to change the standard GTK + icons on the windows
>> build to the tango style also?
> Hi Ryan!
> You mean stuff like open, new, save etc?
> Those are coming in gtk 2.12. Will be released in September.
> - Andreas
Andreas: That's wonderful wonderful news, I'm so glad to hear it. It's going to massively improve a lot of gtk apps for windows users. But for the rest of the inkscape icons - like the drawing tools etc, the windows users will want the tango icons for these as well, simply because they're very much more in keeping with the Windows style. So I agree with ryan; i think we should change these over as soon as we can.
From: Andreas Nilsson <nisses.mail@...563...>
Sent: Saturday, August 25, 2007 10:54 AM
To: ryan lerch <ryanlerch@...400...>
Subject: SPAM-LOW: Re: [Inkscape-devel] Tango Icons
ryan lerch wrote:
> is there any way to change the standard GTK + icons on the windows
> build to the tango style also?
You mean stuff like open, new, save etc?
Those are coming in gtk 2.12. Will be released in September.
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Inkscape-devel mailing list
I have just submitted a patch that implements a "default metadata"
page on the preferences dialog. This defines the default values to be
used as metadata for newly created documents.
I need someone to review this code, please. It works fine for me.
There is just one little issue: I havent been able to figure out how
to update the status of the license radiobuttons on the
documentMetadata dialog. Some more experienced programmer could,
please, take a look at it? I imagine that it may be a simple thing
that is still just not clear enough for me.
This is my first patch for inkscape, so I am not much comfortable yet
with the overall structure of the program.
here is the patch:
I've just merged the first code drop from Nick into SVN; I was hoping to
avoid any regressions, but at this point I think it's more important to
start merging now since Niko and Nick are starting to touch the same
code and I want to avoid too much divergence.
Things that work:
- blend modes can now easily be selected for objects, just like blur
- background accumulation buffer is enabled as-needed
- the filter UI dialog has very very basic filter editing capabilities
- Niko's work in r15171 (non-destructive filter update) needs to be
re-integrated with the new filter metawidget, which replaces the old
- the blur slider in the filter metawidget needs to be made percentage
like the slider it replaced
- add filter metawidget to layers dialog too, for layers
- fix flakiness for "Filter" "blend mode"
- flesh out filters dialog, parameter editing/connections, etc.
I think we'll need to work out who wants to work on what with the
metawidget at this point, depending on what you guys are each most
comfortable spending time doing, and on your respective current states
the cairo-based simple PDF import extension has been in trunk for a
while (well, for a week or so :) ). Now I have committed a preliminary
version of the native libpoppler-based one to trunk (you can activate
it by uncommenting the line Internal::PdfInput::init() in
I did commit this unstable version because I need your help regarding
a strange bug. When a PDF document is opened Inkscape crashes with
segmentation fault, giving the following backtrace:
#0 0xb6ebeb46 in malloc_usable_size () from /lib/tls/i686/cmov/libc.so.6
#1 0xb6ec0ecd in free () from /lib/tls/i686/cmov/libc.so.6
#2 0xb6ec283f in malloc () from /lib/tls/i686/cmov/libc.so.6
#3 0xb70844b7 in operator new () from /usr/lib/libstdc++.so.6
#4 0xb70845ed in operator new () from /usr/lib/libstdc++.so.6
#5 0xb71719d2 in PDFDoc::checkFooter (this=0xa6c5700) at PDFDoc.cc:248
#6 0xb7171e90 in PDFDoc::setup (this=0xa6c5700, ownerPassword=0x0,
userPassword=0x0) at PDFDoc.cc:185
#7 0xb71721c5 in PDFDoc (this=0xa6c5700, fileNameA=0xa6c56c8,
ownerPassword=0x0, userPassword=0x0, guiDataA=0x0) at PDFDoc.cc:102
#8 0x08594ec7 in Inkscape::Extension::Internal::PdfInput::open (
this=0x8857030, mod=0x8861350, uri=0xab497e4 "/home/shudo/tiger.pdf")
Please test whether the same thing happens on your system also (note:
PDF import is not yet available on Windows) and tell us if you have
any ideas regarding the solution to this problem which sets back the
further development of the import extension.
The CMYK color input behaves strangely: in the Fill and Stroke panel, when I try to change the color percentages in the CMYK tab by entering numbers on the right of the color mixers, these numbers are somehow recalculated on the fly and already entered amounts change. Here's an example:
C 0 I change it into 44
M 27 jumps to 0
Y 61 jumps to 47
B 60 jumps to 71
And so on... It is almost impossible to input a CMYK color. Even entering CMYK color amounts with the help of the color sliders (for example MAGENTA) leads to subit changes in other colors (CYAN, YELLOW and BLACK).
Dear fellow Inkscape users,
My Google Summer of Code project is now in SVN. My project is "Raster
Functionality in Inkscape," which involved integrating ImageMagick libraries
into Inkscape, in order to manipulate bitmaps from inside Inkscape.
You'll have to install ImageMagick with Magick++ support (which is default)
in order for these new extensions to work.
They can be accessed under the sub-menu "Raster" in the extensions drop-down
The code is not quite in its final state--I am still perfecting and
smoothing it out--but it's functional and I'd love to get feedback from all
of you, especially from Windows users (because I have not tested it on that
Thank you all,