I've submitted this patch
that activates the Meta (or Apple or Command or Windows Flag) key as
modifier key. It allows to have Mac-like menu accelerators (Command-C
for copying, Command-V for pasting, etc.)
After applying the patch and compiling/packaging, the file
share/keys/mac.xml has to be copied as
The file mac.xml is a copy of default.xml where I brutally found all
occurrences of 'Ctrl' and replaced them with 'Meta'. I'm sure it needs a
more careful approach.
I think there might be a somewhat involved solution to the problem of
integrating mac osx menus in inkscape. Sure having Inkscape with mac-ish
menus would be nice.
It entails creating an invisible window with a menu that is managed by
OSX-integration. When a menu event is generated, the invisible window
delegates the event to the windows that has focus - either via
programmatically triggering the window's own - invisible- menu or by
directly calling the verb/action.
> Your email, unfortunately, made me think that OSX menu integration
> might not be possible, without a major rewriting of the source code.
> Inkscape's architecture (as for the majority of gtk apps) assumes
> that, in multi-document mode, every window has its own private menu
> that receives and process events.
> In OSX, in multi-dicument mode, there is only one menu that processes
> events and dispatches actions to the window that currently has the focus.
> It might not be possible to achieve this type of integration with the
> current state of Inkscape' sources.
Rev 12010 on Kubuntu 12.04
Import a bitmap
Apply a customizable filter
Open the Filters Editor
Now you are unable to live preview the changes of any customizable filter, even if you close and reopen Inkscape !
You must delete Preferences.xml in .config to recover the live preview changes.
Looking for a programmer
to develop a cairo-graphics
demo app of Tau Meta Tau Physica
pattern design software.
This software can be used for
sheet metal and wood working
in addition to garment design.
If you are interested
please contact me at
Hi to all.
I update the 0.48.x branch to the official stable branch instead the development 0.48 branch. The names are changed.
We can find here: https://code.launchpad.net/~jabiertxof in 1 day max.
New to the list but not to compiling gtk programs on Windows.
I decided to try my hand on compiling Inkscape on 64-bit Windows 7 after
users of my Gimp builds urged me to look into Inkscape. However, I am
running into an issue that is not making sense to me. The compile fails on
the ui/dialog part of the tree with a message that giom/dbusmessage.h has
an error in it!. I can post the exact error if needed. However, thought
this might be familiar to veterans out there and so decided to post. I am
using gcc 4.7.2 if that matters.
If/once I am successful, I will be happy to put up builds on my website.
While Googling for 64-bit builds, I see that there is virtually nothing out
there for Inkscape. The SuSE builds are interesting and work. However, the
ui is screwy in that you cannot open any files or save them. In other
words, no dialog box shows up when you run it. So, it's not very useful. :)
Thanks in advance,
Hi to all.
The branch BSpline is update to fix continue previous curve error.
Now is complete for testing.
Feedback are welcome.
De: Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...>
Para: inkscape-devel <inkscape-devel(a)lists.sourceforge.net>
Cc: nemes.sorin <nemes.sorin@...400...>, moduli16 <moduli16@...400...>,
Guiu Rocafort <neandertalspeople@...400...>, Romain de Bossoreille
inkscape-user-brasil(a)lists.sourceforge.net, mp+137463 <mp
Asunto: BSpline + SpiroLive branch is ready for testing.
Fecha: Mon, 24 Dec 2012 08:14:33 +0100
Hi to all.
The branch BSpline is on.
It has the SpiroLive code refactored and the new code BSpline.
It has a new button near spiro, It work in pen and pencil mode.
For developers: I have a problem in code commented in bspline function.
Please anybody can fix? This code is for use continuing existing curves
in CUSP node.
I lost my terribol history of this proyect in bzr because i kill the "bzr merge" command and it corrupt a file in the branch.
Feedback are welcome.
We have a problem with the LPE-system writing to XML *during* the load
process. When loading an SVG with path effects, you can do an undo
operation that bugs.
Upon loading a file, all effects get recalculated, because of "path_set"
being the same for initialization and changes.
Can we fix the situation by simply (re-)initializing the undo system
*after* a file has been fully loaded?
A thought struck me while working with the symbol manager. As it currently
is springtime again, I can't help myself but post this idea here.
Launchpad is not often available to me due to timeouts (3 sec reply limit
reached due to GFW and NSA), sorry for that.
As it now reads <symbol> code and put it neatly into a window, how hard
could it be to let it read <glyph> code and put that in a window. I am
sure that the font designers would be thrilled with it and using
LibreOffice draw to generate SVG fontsets by using its SVG export would
open up a plethora of fonts to the Inkscape community. Including all those
symbol sets, wingbats, sign language symbols and whatever has been put
into ttf, type1 and whatever convertible format. An addition would have to
be to limit the amount of glyphs read at one time as I guess that a full
traditional Chinese character set of 180.000 characters would be a tad
The basic tools are there though and it can't be that hard to have it read
<glyph> rather than <symbol>. Reading the UNC code per 128? incrementally
and adding a number under the glyph display would turn it into a pretty
sophisticated tool for font developers and designers alike.
P.S. I deem myself a lousy coder, otherwise...
I want to try something different with this dev cycle based on
feedback that has been received as well as it being our least
predictable cycle thus far. First, I want to thaw trunk to a degree.
New features are allowed if they really appear to be "complete"...
this means no committing anything that is known to not be fully
implemented, introduce regressions, or otherwise has known issues. On
top of that, if the author of said feature does not have time to
polish/bugfix within a month based on feedback, it's just not the
right time to merge it.
Once we are clearly moving forward toward a release, at that time I
will propose a freeze. Once all blocker bugs are closed out a release
branch will be made. At that point is when string freeze will
officially set in on that release branch. 6 wonderful weeks of further
bug fixes and translating will then take place.
Yes, it seems like the release is "just sitting there" while getting
wrapped up, but one benefit is a planned period to get test builds out
in the wild so we can possibly get an even more stable new release
out. Regular users always catch our oversights, so the more of them
with their hands dirty helps save us some potential bug tracker grief.
Hopefully some other great new stuff has the potential to land in 0.49
now. It's a shame for development to not still charge ahead if
people's work is far along enough. We'll see how this works out this
time and if appropriate perhaps do the same again in future releases.
I will let everyone know when it looks like we should actually go back
into feature, but from where I sit, I don't foresee that being too
As usual, any questions, comments, or feedback are welcome.
TL;DR: We're mostly thawed, but commit quality matters more than
usual. An update will be posted when it's merited.