Tablet stopped work in Dev builds
I just downloaded the Oct 24 Windows build and found that my tablet isn't
working properly with it.
I can move the cursor with tablet pen, but when I press on the tablet
nothing draws. I tried toggling the "Use pressure" button.
My tablet still works fine in 0.46 and was working in an earlier build I was
using last night (I don't think it was more than a week or two old). Let me
know if you require a bug logged for this.
View this message in context: http://www.nabble.com/Tablet-stopped-work-in-Dev-builds-tp20171213p201712...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
13 years, 10 months
Re: [Inkscape-devel] Snapping toolbar
by Diederik van Lierop
Op Vr, 16 januari, 2009 01:39, schreef Rock Star:
> The difference between creating and editing can be somehow seen from the
> video .
That video indeed explains everything! A few months ago I introduced a
snapping delay, which makes snapping in Inkscape much more responsive in
complex documents. That snapping delay is what you noticed when editing
objects, but it apparently it doesn't work when creating objects. I will
fix that. If however you prefer the old behavior without any delay, then
just go the preferences -> snapping and set the delay to zero.
> Now I see the problem with guides and grid and toggles. However, since I
> come more from a CAD world, I'm used of snapping to whatever is visible.
> Hence, if there are 2 grids turned on, I would expect to snap to both.
> would than mean 2 more toggles. If you see grid/guides it snaps, otherwise
Maybe it isn't a problem after all to add an additional toggle in series.
When creating a grid, the per-grid snapping is turned on by default. So if
a user is not aware of this then he won't notice, and if he turns it off
then... well, that's his/here responsibility ;-). So we would end up with
these options in series:
1) the global snapping toggle -> EVERY USER MUST KNOW ABOUT THIS**
2) the GLOBAL grid snapping toggle -> CLEARLY RECOGNIZABLE ON THE TOOLBAR
3) the PER-GRID snapping toggle -> ON BY DEFAULT
4) snap bounding box corners toggle or the snap nodes toggle
-> EVERY USER MUST KNOW ABOUT THIS TOO**
**) ... but only if they care about snapping obviously.
> Anyway, thanks for the answer and additional explanation.
You're welcome. Thanks for your feedback!
13 years, 11 months
Ubuntu nightly builds
by Ted Gould
So I've gotten most of the way on getting a nightly build setup in a
Launchpad PPA. It builds for the current, the previous and the next
release of Ubuntu. What I'm particularly happy about is the package is
"inkscape-devel" so it can be parallel installed with a stable version
of Inkscape. Here's the PPA:
I'm going to run the script by hand for a couple of days to catch errors
but then Cory has graciously allowed me to run it on his server after
that so it should become more regular.
13 years, 11 months
Guide editing by mouse
by Maximilian Albert
as a kind of test for some other things I have in mind I added better
support for editing guides by mouse. You will notice that the anchor
point of guides is now displayed on canvas as a small dot. You can
still move guides as you used to, but now you can also rotate them
around the anchor as well as move the anchor along the guide. What I'm
not really happy with, though, is the way in which the various
functionalities are accessed. So I'd like your help in this respect.
Currently it works as follows:
1) dragging the anchor moves the whole guide (and the anchor with it)
2) pressing Shift and dragging the anchor moves it along the guide
(while the guide itself stays in place)
3) dragging the guide anywhere outside the anchor rotates it around the anchor
4) pressing Shift and dragging the guide outside the anchor bypasses
rotation and moves the whole guide (as in 1.)
Does this make sense to you? Do you have better suggestions as to
which functionality should be accessed in which way/with which
Thanks for your feedback,
Inkscape Export to "JavaFX 1.0 FXD/FXZ Content file" format
by Sergey Esenov
Last year Sun Microsystems released JavaFX Production Suite
(together with JavaFX 1.0) which have Adobe Photoshop CS3
and Adobe Illustrator CS3 plugins for exporting graphical assets
into JavaFX format.
The output (.fxz) is a ZIP archive containing 'content.fxd' file
representing vector graphics picture in JavaFX format.
Optionally, this archive may contain images and fonts referenced by the
'content.fxd' file. The content file can be viewed in netbeans IDE
(JavaFX plugin should be installed!). The netbeans has UIStub generator
for building a JavaFX class based on content.fxd and users may
objects by changing object properties, moving them, animating, making them
visible/invisible and so on. The objects you want to control in JavaFX should
have special prefix in naming of Inkscape "id" attribute like "jfx:object_name".
Others will be anonymous in JavaFX.
I propose that this plugin for Inkscape be used. It is based on the work of
B.Jamison, S.Neto and J.Clarke for JavaFX Export (javafx-out.h, javafx-out.cpp).
My updates to it were posted a few weeks ago.
Personally I consider the "FXD/FXZ Content file" format more useful and I am
going to use this actively in future projects, which explains my motivation.
The implementation is obvious: scan the object's tree and write the
corresponding JavaFX constructs. The output has all attributes embedded in line
therefore the information about gradients, filters and clip-paths are
pointer information) and then used when actual graphic objects in the
scene are built.
Embedded images are decoded and external images are copied into the
output ZIP archive automatically. Fonts should be handled in the same way
Like Illustrator plugin I always try to recognize simple objects
(circles, ellipses, rectangles)
behind the paths to reduce the output size.
As a zip library implementation I used http://www.nih.at/libzip.
Actually I am working with Linux, openSUSE 11.1 distribution, where
this library is
known as libzip1. It seems that Ubuntu distribution supports it as well.
The Windows platform is also supported:
While I might agree that introducing a new dependency into inkscape may not be
welcomed, my attempt to use inkscape/src/dom/util/ziptool.[h,cpp] was unhappy:
extremally slow! (~ 30 secs on some pictures).
It is checked on the following pictures:
-- gradients, embedded images
-- large picture with clip paths
and I have used this simple tutorial to check clipping mask handling
The installation is simple if you are able to build svn version of
inkscape on your platform.
1. Make sure you have libzip1 + libzip-devel packages installed in
your system. Or you should have
this installed from sources. See the reference above for instructions.
2. Get SVN version of inkscape:
svn co https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk
3. Copy 'javafx-fxz.h' and 'javafx-fxz.cpp' from attachment into
4. Create build directory:
5. Add 'javafx-fxz....' entries just above 'javafx-out' entries into
and in the last file (init.cpp) put just before
"Internal::JavaFXOutput::init();" line the following...
6. Go back into inkscape (top) directory and do ...
LIBS="-lzip" ../configure --prefix=/opt/inkscape
CFLAGS="-g -O0" CXXFLAGS="-g -O0" LIBS="-lzip" ../configure
if you want to build inkscape with debug information
make && su -c "make install"
7. Use /opt/inkscape/bin/inkscape executable and enjoy!
Of course, I am interested if some person(s) from development team might review
the code and make a decision. Anyway I hope it will be useful.
Re: [Inkscape-devel] Tango icons as default set
by Guillermo Espertino
worms invasion wrote:
> Well, re. the proposed Tango icon set for Inkscape... I do NOT want to be "forced" to test the Tango icons - let alone to be forced to use them. I hate the Tango icons. :-)
The same argument that Tango people has: We hate that set, we don't want
to be forced to that.
> The main reasons are:
> - they are unreadable, "undecodable".
> I do not need to use a magnifying glass to "decode" the current (non Tango) icon set, the icons are "sharp" and "clear". Compared to them, the Tango icons are... "wtf?... which icon is that...?" I do not want to lose time wondering each time I need to click on an icon (and it happens quite a lot in Inkscape, because I don't use the shortcuts or F-keys). Honestly, I hardly *see* the Tango icons.
Some of the current Tango icons need some contrast tweaking, that's
Plus the non-black outlines give less contrast than black lines, but the
problem with black and dark/black themes is an issue.
Anyway, I don't think they are unreadable, undecodeable or that you need
a magnifying glass to see them.
> - they belong to the Linux world.
They're intended to be multi-platform. Just as Inkscape and other free
applications. Using an icon set created for that purpose is consistent
to a free, open source, multi-platform program.
Other people can argue that free software belongs to linux world and you
shouldn't use it in Windows :-)
> - I do not use any other "free" software which uses the Tango icon set, such as The Gimp or..., so I don't care about "being used" to seeing such or such icons.
That's your point of view. You don't care, and since it's not your
concern you don't consider if others do.
I don't want to bring such discussion to the list, but I'd like to know
why people is using inkscape? Just because it's free of charge?
It's also free (libre) software, and a lot of people cares about that.
Being part of a software movement that's created in a collaborative way
implies to have a goal and work to make it happen.
There are people who sees inkscape just as an application that costs
nothing, but others see it as a part of something bigger.
Theme changers are quite common in shareware/freeware apps for windows,
so I don't think that would be a big deal if we put Tangos as default
and let people change it back to the current set if they don't like it.
That would be enough for them (they won't be forced to Tango) and would
be nice for people who prefers Tango because they fit with the other
In my honest opinion, for people who sees inkscape as a freebie, a UI
option for changing the icon set will be enough.
I don't want to make a political discussion about this, and I'm not
saying that you are that kind of people (i can't speak, I don't know).
> - I believe each application can have its own style, its own icons. I hate the "applications on a platform must all look alike" concept, it's sterile, it's boring, it's dull.
Of course, and nobody denies that, and that's why we need an easy way to
change icon themes from the preferences.
You're talking about what you hate and what you'd love, what would be
amusing, bright and happy and not a technical reason.
People who back up Tango icons ask them to be default for technical
reasons, not just personal preferences
-A normalized icon set with clear design guidelines
-More care about details (pixel alignment, for instance)
-An unified look between free design applications
-Better look in dark gtk themes.
If the current set would cover most of these topics (well, the unified
look with other apps wouldn't be possible) I bet most of the Tango
people would find it acceptable and a easy icon theme changer in the
preferences would suffice.
> So, my user opinion is: if the Linux users are masochists and want to have Tango style icons for Inkscape, fine, give them a GUI to switch to Tango icons.
Again, just change the "Linux" word for "Windows" and change the Tango
word for "current" and that's the way I see it.
This is matter of personal taste. I'd prefer to talk about technical
14 years, 1 month
eraser tool opinions?
by bulia byak
Now that the Eraser tool is in SVN for quite some time, what do people
think of it? Is it useful? In what mode do you use it, if at all?
Disclaimer: as you may remember I was against this tool from the
beginning, considering it redundant. Its Delete mode is equivalent to
Alt+drag followed by Del in Selector, and its Cut mode is now
equivalent to Alt+drag in Calligraphic pen which I just added:
* When drawing with <b>Alt</b>, Inkscape <b>subtracts</b> the path you
have created from the selected path (with <b>Shift</b>, it adds to the
selected path). This allows you to quickly patch or fix problems in a
stroke you have drawn without leaving the tool.
So, do we really have to spend the prime toolbar space on a tool which
does what other tools already do?
Inkscape. Draw Freely.
14 years, 1 month
by Diederik van Lierop
New as of revision #20491: the much requested and long overdue toolbar
with snapping controls!
Please test it and report any bugs. Question to you all: do you think we
can remove the "snap" tabs in the document properties dialog, except for
the snapping distance sliders?
If you don't need it, just turn it off and it won't bother you again. If
you don't like it, then please draw me some new icons. Please forgive,
these are the first icons I've ever drawn :-). Obviously, there are no
Tango icons yet either.
On Linux, please don't forget to do a "make install" to install the new
14 years, 1 month
Re: [Inkscape-devel] LPE cleanup
I just moved almost all 0.47 LPEs to the "experimental" section in the
code. This means that they will not show up in the normal 0.47 builds.
We need to make sure they work and don't crash, that there is a testfile
in the testsuite and that they are useable too.
If you want to build Inkscape with experimental LPEs, make sure
"LPE_ENABLE_TEST_EFFECTS" is defined. You can do that by editing
config.h (in build.xml for windows, on linux I have no clue), or by
editing /src/live_effects/effect.cpp at the start somewhere put:
> -----Original Message-----
> From: Engelen, J.B.C. (Johan)
> Sent: woensdag 7 januari 2009 23:22
> To: bulia byak; Inkscape Devel List; Maximilian Albert;
> Maximilian Albert
> Subject: RE: [Inkscape-devel] LPE cleanup
> Hi all,
> yeah, LPE is a mess :-( I'm sorry I contributed to that :-(
> Recently, I improved the conditional compile of unfinished
> effects. Now, the "test effects" are not compiled, unless one
> #defines LPE_ENABLE_TEST_EFFECTS. So for example, probably
> nobody here has the dynamic stroke LPE in their list, while I
> and jfb have. Have a look in /src/live_effects/effect.cpp
> around line 80 to see how to hide effects that are not finished.
> I am very tempted to move *all* new LPEs since 0.47 to the
> disabled part. Moreover, every effect should have a test svg
> that tests the effect in the testsuite; with a couple of not
> so simple cases of the effect working properly.
> > -----Original Message-----
> > From: bulia byak [mailto:buliabyak@...400...]
> > Sent: woensdag 7 januari 2009 3:57
> > To: Inkscape Devel List; Maximilian Albert; Maximilian Albert
> > Subject: [Inkscape-devel] LPE cleanup
> > Hi guys,
> > what if, as a first step towards 0.47, we clean up the mess
> in our LPE
> > list - remove proofs of concept, hide those that only make
> sense in a
> > tool, merge similar ones per our discussion, remove or fix
> those that
> > crash? Can anyone who's more in the loop please make a list of
> > suggestions?
> > --
> > bulia byak
> > Inkscape. Draw Freely.
> > http://www.inkscape.org
> > --------------------------------------------------------------
> > ----------------
> > Check out the new SourceForge.net Marketplace.
> > It is the best place to buy or sell services for just about
> > Open Source.
> > http://p.sf.net/sfu/Xq1LFB
> > _______________________________________________
> > Inkscape-devel mailing list
> > Inkscape-devel(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
14 years, 1 month