Chris Lilley wrote:
> On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote:
> k> How can I save the file as PNG with the drop shadow intact?
> Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
> (I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list?
One that seems redundant and apparently with less functionality than the
normal export. Is this for testing purposes?
Selector tool has a new mouse cursor (arrow with an open hand) for
when your mouse is over a selectable object, and another (arrow with
clinched hand) for when you're dragging an object. This improves
precision of selection and UI consistency (previously, the mouse
cursor over a selectable object was different across platforms, e.g.
hand icon on Linux or four-way arrow on Windows).
Inkscape. Draw Freely.
I just built the inkscape trunk from bzr and ran this script
bus = dbus.SessionBus()
inkdoc1 = bus.get_object('org.inkscape', '/org/inkscape/desktop_0')
doc1 = dbus.Interface(inkdoc1, dbus_interface="org.inkscape.document")
im = doc1.image(100 ,100, '/home/ktenney/Firefox_wallpaper.png')
Which worked on a dbus branch a while back.
Now it starts inkscape, but does not place the image
- was the dbus code merged?
- if so, how do I enable/use it?
- if not, where is dbus capable code?
Are we still waiting for the SVG standards before we can implement gradient
I have a ( pretty simple and obvious ) method of rendering gradient meshes
that is simpler than blurring multiple beziergons and is quite fast ( 100 ms
in Java rendering 500x500px approx ), I was wondering if we start putting a
basic gradient mesh in inkscape and we can conform/export to the SVG format
when it comes out.
I believe we are trying to get a triangle gradient primitive approved from
SVG. Do we have any plans of getting a quadrilateral primitive ? It will be
more accurate for gradient mesh. This paper I found explains some
quadrilateral rendering techniques :
I finally found time to test the new node tool. Overall it feels
great, but of course I found many small and not so small things to fix
:) #1 is my personal pet peeve, if you can't see it please just give
me pointers to the code which passes events up and I'll have a look
I'll probably have more as I do more testing, but here's the fist batch:
1. Bug: Middle-button dragging and Shift-middle button zoom rubberband
still do not
work. Are you using a mouse with a middle button to test? They work in
Selector but not
2. Lost feature: when rotating/scaling nodes by keys and one node is
mouseovered, it is
used as center of rotation and scaling.
3. Lost feature: when ctrl+alt+dragging a node, it should slide along
the handles _and
4. Lost feature: when ctrl+alt+dragging a node, and it has a linear segment on
one side, it should slide along the continuation of that segment.
5. Lost feature: node sculpting. Will you work on it, or do you want
me to work on porting it?
6. Bug: select a single node and rotate it by  with or without Alt:
it rotates around
some random center far away, instead of around itself.
7. Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The
previous behaviour was:
snap to origin, its opposite and perpendicular, to
vertical/horizontal, and to 15 deg
steps from vertical. This is much more useful because more often, I use Ctrl to
snap it to vertical or some simple angle like 60 deg.
8. Lost feature: create a cusp node next to a linear segment; press Shift+S; it
becomes semismooth, aligned with the segment (correct); now press
Shift+S again; old
behavior is to make it fully smooth, extending the second handle, but
your tool does nothing.
9. Lost feature: Rotating a handle with Shift before allowed to rotate
the second handle
by the same angle, thus rotating a cusp node as a whole; now it does nothing.
10. Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing
selected should do the same in Node tool as in Selector, instead of
doing nothing as
11. Performance: Create a path with thousands of nodes (paste text,
convert to path,
combine), select it in Node tool: notice how slow it all becomes,
freezing for many
seconds, as you simply move your mouse over the path. My guess is that
something on each motion event and does not cache the results. The old
tool also wasn't
very snappy in such situation but it was much better, only freezing
for a couple seconds
at most with the same file (test it!) partly because it cached the livarot
representation of the path it used for proximity/over the path calculations.
12. Lost feature: the statusbar used to say how much total nodes are
there ("2 of 5
nodes selected") and, for a single node, its type (smooth, cusp,
auto). For multiple
subpaths it said e.g. "2 of 9 nodes selected in 2 of 3 subpaths". Now
it only says
"Selected 2 nodes" (which is also a wrong word order, suggesting an
action instead of a
state). Could you please just copy this part from the old node tool?
13. Suggested feature: now that we can select multiple objects, the
statusbar hints must
reflect that, in the same way as subpaths, e.g. "2 of 9 nodes selected in 2 of 3
subpaths in 1 of 2 selected paths", or simply "2 of 9 nodes selected
in 1 of 2 selected
paths" if there are no subpaths involved.
14. Bug: when dragging a node handle, statusbar erroneously says "Move
by" instead of
"Node handle:" as did the old tool.
15. When mouseovering a node, it says "click to select" even if it is already
selected. I'd like to copy this from the old tool as well, which
modifiers for dragging instead.
16. On the node deletion discussion, I found the current behavior
satisfactory: if you
Del, you get curved approximation; if you Ctrl+del you get linear segment from
linears. I think this is logical (unless I miss something).
17. UI suggestion: since the show/hide seltrans handles button belongs
it should be moved to the right end of the controls bar, next to node
handles and node
18. Crash: draw a path; draw a path and apply it as mask; draw another
and apply as
clippath; go to node tool; enable both mask and clippath editing; drag
a mask node; drag
a clippath node; drag a node of the path itself; undo 4 times - crash.
19. UI bug: create with Pen a Spiro path; now switch to Node tool -
the green outline of
the source path is visible always, even when "show outline of path"
toggle is off and
"show path parameter" was never pressed. Also, as we discussed in the summer, I
suggested a purple color for LPE parameter paths, so they are not confused with
20. Crash (somewhat hard to reproduce): With Pencil in Spiro mode,
create a path with
just two nodes (click, click). Now create a curved doodle path
(unrelated bug in Pencil:
you need to deselect first path before drawing second, otherwise they
joined!). Now select both paths, go to Node. Select the end node of
the linear path and
start node of the curved path. Mouseover the latter and press Shift+J.
Then press Ctrl+Z
while still mouseovering the joined node. Crash:
Program received signal SIGSEGV, Segmentation fault.
Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060
#0 Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060
#1 0x085fc574 in Inkscape::UI::CurveDragPoint::_getTip
(this=0xb8d57c8, state=4) at ui/tool/curve-drag-point.cpp:152
#2 0x085fadc1 in Inkscape::UI::ControlPoint::_updateTip
(this=0xb8d5790, state=4) at ui/tool/control-point.cpp:470
#3 0x085fb914 in Inkscape::UI::ControlPoint::_setMouseover
(p=0xb8d5790, state=4) at ui/tool/control-point.cpp:460
#4 0x085fc122 in Inkscape::UI::ControlPoint::_eventHandler
#5 0x085faad8 in Inkscape::UI::ControlPoint::_event_handler
#6 0x0824dd28 in sp_marshal_BOOLEAN__POINTER (closure=0xb5c0270,
marshal_data=0x85faac0) at helper/sp-marshal.cpp:352
#7 0x0056a072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8 0x0057f7a8 in ?? () from /usr/lib/libgobject-2.0.so.0
#9 0x005809b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#10 0x012b38ee in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x081c66df in emit_event (canvas=<value optimized out>,
event=0xb8d57c8) at display/sp-canvas.cpp:1348
#12 0x081c68e3 in pick_current_item (canvas=0x985c060, event=<value
optimized out>) at display/sp-canvas.cpp:1491
#13 0x081c9431 in sp_canvas_motion (widget=0x985c060, event=0xaf58340)
Inkscape. Draw Freely.
I tried to dmg inkscape 047 X11 - but ended up with an image, which
contains a link to /Applications and a folder called "Contents" -
which seems not to be a .app bundle.
When running the osx-dmg.sh, I get the message:
osascript: dmg_set_style.scpt: No such file or directory
In fact, the dmg_set_style.scpt cannot be found on my machine, it
looks as if it were contained by earlier source packages and dropped
Could somebody be so kind and mail me the script - or - in the case -
guide me to another solution of that problem.
I have some doubts about the adaptable UI feature.
Part 1: UI issues
- The UI mode selection combo box (called "Task" for some reason) has
usability problems: 1. it jumps around when changing mode, so every
time I change it, I have to find it again to try another mode; 2. when
the main commands toolbar is vertical, it causes a very large
horizontal padding on it, even when it's hidden in the overflow menu.
- Tearing off toolbars does not adjust their size to fit the controls.
If I tear off a toolbar from a small window, I get a toolbar with an
overflow menu. If I tear off from a maximized window, I get a toolbar
with lots of unused space. This makes tearing off highly useless.
- Toolbars can be torn off but can't be attached in a location
different that the original one. This is because they use
GtkHandleBox, for which the docking position is fixed. At the same
time GDL has a widget named GdlDockBar which sounds like a true
dockable toolbar (but it might as well be something else, I don't
Part 2: UxManager class
- UxManager::setTask: Magic constants in switch.
- UxManager constructor: "tags" is created but doesn't do anything.
- What is the point of having several desktops attached to one UxManager?
Part 3: util/ege-tags.h, util/ege-tags.cpp
- ege-tags.h: It supposedly implements
http://create.freedesktop.org/wiki/ResourceTagging but at present I
don't see any place in Inkscape that could make use of tagging.
- Even if the aforementioned specification was good, the UxManager
class apparently tries to do two completely unrelated things: manage
external resources and change the UI mode.
- TagSet: if I understand correctly what this class attempts to do, it
should use std::tr1::unordered_map<Tag, int> with appropriate hash and
equality predicates instead of the combination of std::vector<Tag> and
Part 4: other problems
- toolbox.cpp:1578: code related to changing the UI layout uses a
switch to assign function pointers. Polymorphism should be used
This is where 0.48 as a "release" begins! This email will be a little
redundant for developers, but will let users know what the current plan
is. The next stage (Frost) kicks into gear at the beginning of March in
case you were wondering.
For right now:
*New feature development will focus on wrapping up.
*We will identify "make check" issues (we need to make sure things are
"friendly" for packaging).
*We will run an About Screen contest on DeviantART (which I will
announce within the next 24 hours and post all info to both lists).
*Ensure that the Release Notes are at First Draft stage. This is
primarily a developer task, however, if you are a user and follow
development closely and have something to contribute in this area which
we may have overlooked, such as fixed bugs, changes in functionality,
etc. please contribute.
*Update tutorials and other docs (we could use volunteers). Not joking,
if you are an Inkscape user and have the misconception that the only way
you can contribute is by code, you are missing out on one of the most
important things for our users... documentation. If you have time to
spare and some tips for others that you're willing to share, please let
--- boring developer junk ---
I do want to request from developers... most "big" new stuff be
committed by March 1st if possible (or shortly thereafter).
JonCruz: The swatch previews for "auto" swatches are starting to worry
me given that they have not been working for quite a while now (since
0.47 dev cycle). The same goes for the method of editing color (gradient
editor rather than F&S dialog). If you will not have time to address
these before Freeze, please expect that I will request the feature is
disabled again for this release at that time... I will also request that
in 0.49 that you not re-enable it until you are looking to actively work
Krzysztof: The new Node Tool is fantastic. I know you're actively
working on it, but I do just want to make sure that you will be able to
set aside a few hours here and there for bugfixing as there are still a
number of bugs and features missing from previous releases.
Arcadie/Michael: The Connector Tool really is not consistent with the
behavior of other tools. If it is not likely to be sorted out by Freeze,
I will request that at least the tool controls button for "add
connection point" be disabled, as it is not user friendly at this point.
Please know that I am not targeting people or criticizing their work.
This is a schedule issue and our date of release was horribly far behind
schedule for the past couple releases. We will just be sticking to
release schedules much more strictly than we have previously, and if
features aren't "bug-free"/complete enough to release on time... there's
always next release! :) Besides, we're going to be in the trenches w/
0.49 for a bit by what has been discussed so far.
M> Unfortunately it's not a simple answer, and I haven't had a lot of time
M> yet since getting back from London. The most useful place for MT is in
M> software rendering. There are not many other places in the codebase
M> which would really benefit from it.
I would like to know why multi-threading haven't been realized in
Inkscape for so long time, many users wrote that they would like to
have full power of theit multi-core processors. I'm starting doing
this work and I want to know what are the difficulties, is it real to
complete in 2.5 months working 8 hours per day? And tell me please as
more as you can about this problem in Inkscape.