8:40 p.m.
The new node tool is now in the trunk - please test and report any
bugs. I made a few last minute improvements inspired by the
discussion.
New features are listed in the release notes:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Node_Tool
I also made a new icon for the spray tool. It's much better than the
old one, but there's still something not quite right with it.
Regards, Krzysztof
10 p.m.
On Thu, 2010-01-14 at 19:40 +0100, Krzysztof Kosiński wrote:
The new node tool is now in the trunk - please test and report any
bugs.
It appears that Ctrl+Alt+Click to create/delete nodes didn't make it
into the rewrite. When I'm using the Node Tool, that command for both of
those operations are definitely preferred for me. If you are unfamiliar
with this shortcut, try it in the Gradient Tool (it works the same to
create/delete gradient stops).
Arcadie, I really hope that this same command gets added to the
Connector Tool for creating/deleting connection points on a selected
object. This would really make sense for consistency between tools and
usability.
Cheers,
Josh
10:15 p.m.
2010/1/14 Krzysztof Kosiński <tweenk.pl@...400...>:
The new node tool is now in the trunk - please test and report any
bugs.
Middle click to zoom in does not work. I think we discussed this in
the summer and you fixed it then, or am I misremembering?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
4:56 a.m.
On Thu, 2010-01-14 at 19:40 +0100, Krzysztof Kosiński wrote:
The new node tool is now in the trunk - please test and report any
bugs.
*I can't reverse a path. Neither Shift+R in the Node Tool, nor
Path>Reverse seem to achieve it.
*LPE: Switcher does not show with Knot LPE.
*LPE: It appears that the coordinates are reversed/mirrored vertically
for LPEs on canvas. Try Bend, it places the on-canvas path for bending
at the opposite vertical position on-canvas (not on top of the object),
it then bends in the opposite direction from what's expected.
*~suv also commented on irc (and I'm not sure if this is known since you
commented on some snapping stuff): "I have also issues with snapping a
selection of several nodes: each time snapping occurs, they move further
apart, changing the geometry of the segments."
Cheers,
Josh
5:10 a.m.
On Thu, 2010-01-14 at 18:56 -0800, Joshua A. Andler wrote:
On Thu, 2010-01-14 at 19:40 +0100, Krzysztof Kosiński wrote:
> The new node tool is now in the trunk - please test and report any
> bugs.
*I can't reverse a path. Neither Shift+R in the Node Tool, nor
Path>Reverse seem to achieve it.
Clarification, if there are no nodes selected.
Cheers,
Josh
1:24 p.m.
W dniu 15 stycznia 2010 03:56 użytkownik Joshua A. Andler
<scislac@...400...> napisał:
*LPE: Switcher does not show with Knot LPE.
Can you give me screenshots of what happens and what should happen?
I'm not very familiar with LPEs.
As for the middle click to zoom: I recall doing something related to
quick zoom, but I'm not sure how it's supposed to work. 0.47 just
zooms in a bit (like Ctrl+mouse wheel up).
Regards, Krzysztof
5:34 p.m.
2010/1/15 Krzysztof Kosiński <tweenk.pl@...400...>:
As for the middle click to zoom: I recall doing something related to
quick zoom, but I'm not sure how it's supposed to work. 0.47 just
zooms in a bit (like Ctrl+mouse wheel up).
No. "Quick zoom" is entirely different. Middle click must zoom in or
out with shift, middle drag must pan, shift+middle drag must start
rubberband zoom. This is a basic way of navigation for me and I'm sure
others. All you need to fix it is to pass middle button events to
event-context which will take care of that.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
6:27 a.m.
2010/1/15 bulia byak <buliabyak@...400...>:
No. "Quick zoom" is entirely different. Middle click must
zoom in or
out with shift, middle drag must pan, shift+middle drag must start
rubberband zoom. This is a basic way of navigation for me and I'm sure
others. All you need to fix it is to pass middle button events to
event-context which will take care of that.
Of these listed here, only click to zoom works now. Can't you just
pass ALL middle click events up?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:53 a.m.
W dniu 21 stycznia 2010 05:27 użytkownik bulia byak
<buliabyak@...400...> napisał:
Of these listed here, only click to zoom works now. Can't you
just
pass ALL middle click events up?
For me, all of those work (middle click, middle drag, shift+middle drag).
I am passing up all events except left mouse button clicks, which
trigger rubberband selection.
2010/1/21 LucaDC <dicappello@...2144...>:
Well, it depends on what you think "preserving shape" does
mean: to me it
means that a straight line should remain a straight line.
To me "preserving shape" means "preserving shape" not "preserving
type
of segments": the path after deleting nodes is adjusted so that it
looks similar to the original path.
I recognize that the previous behavior can be convenient, but it's
quirky: what you obtain depends on whether any of the surrounding
segments has a handle extended, and to obtain a fit to shape, you need
to minimally extend one of the handles. Isn't it better to explicitly
say what you want with Ctrl+Del? (By the way, previously Ctrl+Del on a
node between two linear segments did exactly the same thing as Del;
there was no way to get the shape readjustment behavior on such
nodes.)
Regards, Krzysztof
4:43 p.m.
Krzysztof Kosiński wrote:
To me "preserving shape" means "preserving shape" not
"preserving type
of segments": the path after deleting nodes is adjusted so that it
looks similar to the original path.
I recognize that the previous behavior can be convenient, but it's
quirky: what you obtain depends on whether any of the surrounding
segments has a handle extended, and to obtain a fit to shape, you need
to minimally extend one of the handles. Isn't it better to explicitly
say what you want with Ctrl+Del? (By the way, previously Ctrl+Del on a
node between two linear segments did exactly the same thing as Del;
there was no way to get the shape readjustment behavior on such
nodes.)
Regards, Krzysztof
Ok, let me say that we have different ideas on what "preserve shape" means.
This means that we should discuss on this, rather than taking it as a
starting point.
And also, it's something that probably needs more than our two opinions to
be heard.
I think that what you say is conceptually wrong: a segment is different than
a straight curve. If you think that a path is _always_ made of curves, then
your proposal could be considered correct. But a path _is not_ always made
of curves. The paths I work with are not made of curves but of segments.
Then if deleting a node converts my paths to curves I can't consider this as
"preserving shape" because you are also changing the constructing structure
of the object I'm working with. It's like converting a circle to a path:
it's not a circle as it doesn't have a center and a radius anymore, also if
the "shape" is almost the same. With this assumption, I consider that having
del and ctrl-del doing the same thing on segments is perfectly coherent as
there's no way to preserve the shape of segments if you delete a node (if
the node is not aligned with its neighbours, of course). And also, defining
the current behavior as "preserving shape" as from your point of view is
very subjective: draw a triangle or a square and delete a node... do you
really consider this as "preserving shape"?
More, what you say is:
- if you press a single key, Inkscape is going to change the type of the
object you are working with, i.e. changing it's properties;
- if you want Inkscape to preserve the object type and properties, you need
to press a combination of two keys.
This seems to me very couterintuitive, and also very annoying as the
combination ctrl-del needs either to use both hands (i.e. leaving the mouse)
or using the left hand in the right part of the keyboard. This means I'm
going to be _always_ very uncomfortable with deleting nodes for the
advantage of who?
And I'm never going to use the ctrl-alt click or whatever to delete nodes
because the only way I have to do it is using ctrl-del.
I can only consider this a lack of functionality, or maybe simply a bad
implementation.
And if this all is not enough, all the programs I know (they are not so many
but I suppose they are a good reference) leave segments as segments when
deleting nodes and this is probably what users expect (but I definitely need
to hear more opinions on this). If so, is there a good reason to have
Inkscape behave differently?
Solution? I have two:
1) the old behavior: segments are left segments and curves' shape is
preserved; and you always have the possibility to convert segments to
straight curves if you really need the current (strange) behavior; everybody
happy: why not?
2) wait for more feedback: if you start hearing people complain maybe it's
better to review the choice, otherwise either everything is fine or maybe
not so many people are using Inkscape for technical drawings.
Regards
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27274213.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
5:06 p.m.
2010/1/22 LucaDC <dicappello@...2144...>:
Ok, let me say that we have different ideas on what "preserve
shape" means.
This means that we should discuss on this, rather than taking it as a
starting point.
"Preserve shape" = "Preserve approximate look of the path", not
"Preserve segment type" or "Preserve node type".
What about adding Ctrl+Shift+click as deleting a node without
preserving shape? My concern is that the behavior of Del differs
depending on the type of surrounding segments, and it's not possible
to get one of the behaviors for nodes between two linear segments
without extra steps. I would like it to always work the same, which is
more consistent.
More, what you say is:
- if you press a single key, Inkscape is going to change the type of the
object you are working with, i.e. changing it's properties;
- if you want Inkscape to preserve the object type and properties, you need
to press a combination of two keys.
This was the case even before the rewrite. Try converting an ellipse
to path and deleting one of its nodes. The surrounding nodes are
changed to cusp nodes, and their handles are adjusted. Some properties
of the path (types of nodes) are clearly not preserved.
Regards, Krzysztof
6:11 p.m.
Krzysztof Kosiński wrote:
2010/1/22 LucaDC <dicappello@...2144...>:
> Ok, let me say that we have different ideas on what "preserve shape"
> means.
> This means that we should discuss on this, rather than taking it as a
> starting point.
"Preserve shape" = "Preserve approximate look of the path", not
"Preserve segment type" or "Preserve node type".
Well, this is your interpretation. I see no more strength in linking
"approximate look" to "shape" rather than linking "type of
shape" (i.e.
straight) or "node type". More, if we are talking about "shape", the
type of
line is much more related to "shape" rather than "approximate look".
What is
more similar to a rectangle: an ellipse or a trapezioid? Too much subjective
to be so sure about its correctness. Why not taking other programs as
reference? Probably people is going to expect their behavior if they are
consistent between them.
Krzysztof Kosiński wrote:
What about adding Ctrl+Shift+click as deleting a node without
preserving shape? My concern is that the behavior of Del differs
depending on the type of surrounding segments, and it's not possible
to get one of the behaviors for nodes between two linear segments
without extra steps. I would like it to always work the same, which is
more consistent.
You think that the behavior differs from the programmer point of view, but
from the user point of view it's exactly the opposite.
I think that the behavior more expected and understandable from the user
should be implemented.
Also, accelerators are good for quick operations. But what if you want to
delete a bunch of nodes? You select them and press del... Everywhere works
in this way.
Krzysztof Kosiński wrote:
> More, what you say is:
> - if you press a single key, Inkscape is going to change the type of the
> object you are working with, i.e. changing it's properties;
> - if you want Inkscape to preserve the object type and properties, you
> need
> to press a combination of two keys.
This was the case even before the rewrite. Try converting an ellipse
to path and deleting one of its nodes. The surrounding nodes are
changed to cusp nodes, and their handles are adjusted. Some properties
of the path (types of nodes) are clearly not preserved.
And this still happens. Do you think that converting a smooth node to a cusp
node is preserving the shape?
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27275686.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
6:24 p.m.
On Fri, 2010-01-22 at 08:11 -0800, LucaDC wrote:
Krzysztof Kosiński wrote:
>
> 2010/1/22 LucaDC <dicappello@...2144...>:
>> Ok, let me say that we have different ideas on what "preserve shape"
>> means.
>> This means that we should discuss on this, rather than taking it as a
>> starting point.
>
> "Preserve shape" = "Preserve approximate look of the path", not
> "Preserve segment type" or "Preserve node type".
>
Well, this is your interpretation.
No, it's actually very accurate for the intended meaning of the word
shape in that context. It's to preserve the shape of an object as best
as possible when removing a node.
The problem here is that this is a user preference issue. I think
Artistic users will like the new behavior and Technical users will
dislike it. I too was a bit alarmed at the difference in behavior the
first time I deleted a node on a rectangle. However, when I thought
about why it was happening it made perfect sense to me.
Perhaps the suggested solution of a different modifier to delete without
preserving shape is necessary. Another option I see is a toggle in
preferences for the preferred deletion method with the Ctrl+Alt+Click
modifier.
Hopefully bulia will chime in with an opinion.
Cheers,
Josh
7:37 p.m.
Joshua A. Andler-2 wrote:
> > "Preserve shape" = "Preserve approximate look of the path",
not
> > "Preserve segment type" or "Preserve node type".
> >
> Well, this is your interpretation.
No, it's actually very accurate for the intended meaning of the word
shape in that context. It's to preserve the shape of an object as best
as possible when removing a node.
Saying that "Preserve shape" means "to preserve the shape of an object as
best
as possible" doesn't add anything to this discussion. There's nothing new
from "Preserve approximate look of the path". And it's not "very
accurate",
it's simply as subjective as before.
It seems to me that the problem is: what is "shape"?
Probably if we are talking about curved lines, the problem is dummy and we
all agree.
But when coming to straight lines it's different. What does mean "preserve
the shape when removing a node from a segmented path"? Is it for sure: "make
some segments become curved lines"?
I see no accuracy in this interpretation. To me, if I remove a node from a
rectangle, it becomes a triangle, not a mix of straight and curved lines
that nobody would define similar to a rectangle.
The problem is that you cannot preserve the shape of a segmented path when
you delete a node so having this behavior as default looks very, very
strange to me.
About user's preference: I do technical drawing and I expect that removing a
node from an ellipse converted to a path keeps all nodes smooth and keeps
the overall shape as much similar as possible to the original one. Just like
(you say) artistic users do. On the other hand, I'm not sure that artistic
users do expect the current behavior on straight paths.
And I'm not concerned about the ctrl-alt-shift-tab-esc click: when modifiers
are involved, you can always learn to use the correct one, whatever it be.
The problem is when you press "del" (or "canc"), that is the default
way to
delete something. Again, there are other graphical programs out there: is it
evil taking a look at what they do?
Anyway, I'm not going any further in this discussion until someone else will
support my opinion. If I'm alone there's no point in insisting. I don't want
to force my point of view at any cost.
Maybe, if you think it helps, I could open a new bug report in Launchpad,
just to collect more opinions.
Thanks.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27277187.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
12:51 a.m.
-----Original Message-----
From: LucaDC [mailto:dicappello@...2144...]
Sent: vrijdag 22 januari 2010 18:38
To: inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] Node tool committed to trunk
Probably if we are talking about curved lines, the problem is
dummy and we all agree.
But when coming to straight lines it's different. What does
mean "preserve the shape when removing a node from a
segmented path"? Is it for sure: "make some segments become
curved lines"?
I see no accuracy in this interpretation. To me, if I remove
a node from a rectangle, it becomes a triangle, not a mix of
straight and curved lines that nobody would define similar to
a rectangle.
The problem is that you cannot preserve the shape of a
segmented path when you delete a node so having this behavior
as default looks very, very strange to me.
I agree. I too mainly use Inkscape for technical drawing; deleting a
node from a path with only straight lines (polygon?) should keep all
lines straight. The current behaviour is very strange to me too.
-johan
6:50 a.m.
Hi all,
just a quick chiming in from my part. Disclaimer: I haven't even tried
the new behaviour yet (but hopefully will soon), but I've followed the
discussion so far and I must say that I agree with Luca's and Johan's
point of view:
I agree. I too mainly use Inkscape for technical drawing; deleting a
node from a path with only straight lines (polygon?) should keep all
lines straight. The current behaviour is very strange to me too.
It may be a slightly biased opinion, but I don't believe it's a weird
one or one that only affects a few users, so it should be taken
seriously IMHO.
Max
6:20 p.m.
On 22/1/10 10:53, Krzysztof Kosiński wrote:
I recognize that the previous behavior can be convenient, but
it's
quirky: what you obtain depends on whether any of the surrounding
segments has a handle extended, and to obtain a fit to shape, you need
to minimally extend one of the handles. Isn't it better to explicitly
say what you want with Ctrl+Del? (By the way, previously Ctrl+Del on a
node between two linear segments did exactly the same thing as Del;
there was no way to get the shape readjustment behavior on such
nodes.)
Besides the discussion about what 'preserve shape' means:
a) could you revisit the code for the 'Ctrl+Del' shortcut (respectively
'Ctrl+Backspace' with some keyboards)? I'm trying to adjust to use it,
but repeatedly Inkscape just froze after using the command several (like
2-4) times while node-editing the same path [1].
Unfortunately I can't offer backtraces (or similar debug info) because
when Inkscape freezes, I only know to 'force quit' it - not emergency
save (sigh), no console messages, not CrashReporter log, sorry.
I have not seen this when using <Backspace> without modifier to delete
nodes while preserving the overall shape.
b) can you confirm that this shortcut will *not* be user-configurable
via 'inkscape/keys/default.xml' as I suspect [2]?
~suv
[1] I don't have a list of steps to reproduce the crash. But it happens
repeatedly while working on a custom icon set (icons.svg) - using mainly
the select tool to transform shapes & paths, the node tool to adjust /
snap single/selected nodes and the path operations union, difference,
division and combine - no LPEs or overly complex objects involved.
Besides the issue with <Ctrl>+<Backspace> I have seen repeated crashes
in path operations after having node-edited one of the involved paths,
possibly tied to a prior 'Undo' while node-editing - I'll report that
when I have found a reproducible case.
[2] it is not a very comfortable key combination to use on a mac laptop
(Ctrl+<Backspace>, no <DEL> available) - every time I have to let go of
the mouse and use both hands on the keyboard.
8:58 p.m.
W dniu 24 stycznia 2010 17:20 użytkownik ~suv
<suv-sf@...58...> napisał:
a) could you revisit the code for the 'Ctrl+Del' shortcut
(respectively
'Ctrl+Backspace' with some keyboards)? I'm trying to adjust to use it,
but repeatedly Inkscape just froze after using the command several (like
2-4) times while node-editing the same path [1].
Should be fixed in r9020, there was a case when an infinite loop could
be triggered when deleting nodes.
b) can you confirm that this shortcut will *not* be
user-configurable
via 'inkscape/keys/default.xml' as I suspect [2]?
For now it probably won't be, because there is no verb associated with it.
The new behavior is not yet decided. Right now it's 3:2 in favor of the old one.
There's a third possibility:
- Del = old behavior of delete, depending on the type of nodes
- Shift+Del = delete without preserving shape (corresponds with
Windows/Gnome shortcut to delete without moving to trash)
- Ctrl+Del = delete preserving shape
Regards, Krzysztof
12:26 p.m.
Krzysztof Kosiński wrote:
W dniu 24 stycznia 2010 17:20 użytkownik ~suv
...
Should be fixed in r9020, there was a case when an infinite loop could
be triggered when deleting nodes.
> b) can you confirm that this shortcut will *not* be user-configurable
> via 'inkscape/keys/default.xml' as I suspect [2]?
For now it probably won't be, because there is no verb associated with it.
The new behavior is not yet decided. Right now it's 3:2 in favor of the old one.
There's a third possibility:
- Del = old behavior of delete, depending on the type of nodes
- Shift+Del = delete without preserving shape (corresponds with
Windows/Gnome shortcut to delete without moving to trash)
- Ctrl+Del = delete preserving shape
Do I understand correctly that this would correspond to:
Del: preserve type of nodes
adjust handles to preserve shape as much as possible
Shift+Del: preserve type and handles of nodes
might cause a change in shape
Ctrl+Del: preserve neither type nor handles of nodes
shape is matched as much as possible
1:32 p.m.
Jasper van de Gronde wrote:
Krzysztof Kosiński wrote:
> W dniu 24 stycznia 2010 17:20 użytkownik ~suv
>...
>
> Should be fixed in r9020, there was a case when an infinite loop could
> be triggered when deleting nodes.
>
>> b) can you confirm that this shortcut will *not* be user-configurable
>> via 'inkscape/keys/default.xml' as I suspect [2]?
>
> For now it probably won't be, because there is no verb associated with
> it.
> The new behavior is not yet decided. Right now it's 3:2 in favor of the
> old one.
>
> There's a third possibility:
> - Del = old behavior of delete, depending on the type of nodes
> - Shift+Del = delete without preserving shape (corresponds with
> Windows/Gnome shortcut to delete without moving to trash)
> - Ctrl+Del = delete preserving shape
Do I understand correctly that this would correspond to:
Del: preserve type of nodes
adjust handles to preserve shape as much as possible
Shift+Del: preserve type and handles of nodes
might cause a change in shape
Ctrl+Del: preserve neither type nor handles of nodes
shape is matched as much as possible
Has any decision been taken on how nodes should be deleted?
Some other opinions have been expressed but I've not seen any activity
following them nor any change in the implemented behavior (I finally managed
to reset my compiling environment after all latest changes in devlibs and
compiler; I hope they are not going to change again soon :). Hence I assume
that this issue is still open: is it going to be considered in the near
future or should I open a new bug report (also if it's not a bug, indeed),
just to extract it from this thread and have a reminder?
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27466567.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9:53 p.m.
On 24/1/10 19:58, Krzysztof Kosiński wrote:
W dniu 24 stycznia 2010 17:20 użytkownik ~suv
<suv-sf@...58...> napisał:
> a) could you revisit the code for the 'Ctrl+Del' shortcut (respectively
> 'Ctrl+Backspace' with some keyboards)? I'm trying to adjust to use it,
> but repeatedly Inkscape just froze after using the command several (like
> 2-4) times while node-editing the same path [1].
Should be fixed in r9020, there was a case when an infinite loop could
be triggered when deleting nodes.
I did not see any more 'freezes' with r9020 when deleting nodes, but I
noticed that it fails (as if it is disabled) when 'Show the Bezier
handles of selected nodes' option is turned off:
steps to reproduce:
1) start Inkscape with default preferences
2) create a path (e.g. with the pen tool)
3) switch to node tool
4) deactivate 'show handles..' in the controls bar
5) select one of the mid-nodes and delete it (with <Del> or using the
'-' button on the controls bar) -> fails
6) activate the 'show handles..', try to delete it -> fails
7) toggle tool with <space> and back, try again -> delete now works
not reproduced with Inkscape 0.47 r22583.
~suv
9:27 p.m.
W dniu 27 stycznia 2010 20:53 użytkownik ~suv
<suv-sf@...58...> napisał:
I did not see any more 'freezes' with r9020 when deleting
nodes, but I
noticed that it fails (as if it is disabled) when 'Show the Bezier
handles of selected nodes' option is turned off:
Good find! Fixed in r9027.
If you have any examples of incorrect behavior of the "edit next LPE
parameter" button, or other instances of wrong LPE behavior, send me
an example file.
Regards, Krzysztof.
11:05 p.m.
On 28/1/10 20:27, Krzysztof Kosiński wrote:
If you have any examples of incorrect behavior of the "edit next
LPE
parameter" button, or other instances of wrong LPE behavior, send me
an example file.
In the attached file, turn off layer 'snowflake' and inspect the LPE of
the remaining part of the star (showing the result of 3 VonKoch
iterations): there are two LPE parameters that can be edited on-canvas,
toggling between them is not as simple as in inkscape 0.47:
a) use buttons in the Path Effect Editor: repeated editing of the two
parameters only works if one switches from the node tool back to the
select tool, then uses the button in the dialog to switch to the node
tool again to edit one of the parameters on-canvas. In Inkscape 0.47 you
can switch between the two parameters within the node tool.
b) using the button on the node tool controls bar: now it works once
(i.e. it initially lets you change the parameter path to be edited once
but not toggle between the available parameters). In Inkscape 0.47 you
can cycle through all available parameters.
Another issue I see when node-editing LPE parameters: while the location
of the parameter path now is no longer mirrored/up-side-down, it some
times seems to be off by a smaller vector, at least e.g. when initially
editing the 'generating path' of the VonKoch LPE. My example doesn't
show this, I'll test it for other LPEs and will possibly attach a file
with examples later.
~suv
p.s. the Snowflake/VonKoch example is made following Tav's tutorial at
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-VonKoc...
11:31 p.m.
W dniu 28 stycznia 2010 22:05 użytkownik ~suv
<suv-sf@...58...> napisał:
In the attached file, turn off layer 'snowflake' and inspect
the LPE of
the remaining part of the star (showing the result of 3 VonKoch
iterations): there are two LPE parameters that can be edited on-canvas,
toggling between them is not as simple as in inkscape 0.47:
The underlying problem was that both parameters were considered to be
the same editable object, because the LPE parameter name was not
compared. Fixed in r9029.
Regards, Krzysztof
12:41 a.m.
On 28/1/10 22:31, Krzysztof Kosiński wrote:
W dniu 28 stycznia 2010 22:05 użytkownik ~suv
<suv-sf@...58...> napisał:
> In the attached file, turn off layer 'snowflake' and inspect the LPE of
> the remaining part of the star (showing the result of 3 VonKoch
> iterations): there are two LPE parameters that can be edited on-canvas,
> toggling between them is not as simple as in inkscape 0.47:
The underlying problem was that both parameters were considered to be
the same editable object, because the LPE parameter name was not
compared. Fixed in r9029.
r9029 looks good :)
Envelope Deformation is another good LPE for testing this: it has 4
parameters that can be edited as paths on-canvas. The (initial) location
of the parameter paths of the 'Envelope' LPE is as expected when editing
them (unlike with VonKoch). Cycling through all four parameters works
like a charm now. Thx!
Another minor difference I forgot to mention compared to Inkscape 0.47:
previously all path outlines of parameters that could be node-edited
were visible i.e. highlighted (in green) in node-editing mode, not only
the one currently being edited (which was distinguishable by the
visibility of the node markers). IMHO it helped a lot with editing if
there's a (visual) relation between them (i.e. I miss it ;-). And -
enabling snapping to the nodes of other parameters of the same path
would be a great new feature!
~suv
11:16 p.m.
-----Original Message-----
From: Joshua A. Andler [mailto:scislac@...400...]
Sent: vrijdag 15 januari 2010 3:57
To: Krzysztof Kosiński
Cc: inkscape-devel
Subject: Re: [Inkscape-devel] Node tool committed to trunk
On Thu, 2010-01-14 at 19:40 +0100, Krzysztof Kosiński wrote:
> The new node tool is now in the trunk - please test and report any
> bugs.
*I can't reverse a path. Neither Shift+R in the Node Tool, nor
Path>Reverse seem to achieve it.
*LPE: Switcher does not show with Knot LPE.
*LPE: It appears that the coordinates are reversed/mirrored
vertically for LPEs on canvas. Try Bend, it places the
on-canvas path for bending at the opposite vertical position
on-canvas (not on top of the object), it then bends in the
opposite direction from what's expected.
Another LPE issue:
it is no longer possible to edit parameters on-canvas, like the points in LPE-Hatches.
1:05 p.m.
*LPE: Switcher does not show with Knot LPE.
Another LPE issue:
it is no longer possible to edit parameters on-canvas, like the points in LPE-Hatches.
It was actually the same issue - it should be fixed now.
The Knot LPE doesn't show the curved arrow around the point yet, and
the outline of the original path is always shown. I guess there should
be a flag that allows the effect to specify whether it wants to always
display the outline, or only when the the "show outline" toggle button
is on.
*LPE: It appears that the coordinates are reversed/mirrored
vertically
for LPEs on canvas. Try Bend, it places the on-canvas path for bending
at the opposite vertical position on-canvas (not on top of the object),
it then bends in the opposite direction from what's expected.
Partially fixed (at least for Bend). I don't know whether the edit
transform I now use is always correct. If anyone has more issues with
misplaced LPE editing controls, please send me files which exhibit
this problem.
The issue with LPE parameters not changing when the "edit next
parameter" button is clicked isn't fixed yet. There are also crashes
when all nodes of an LPE parameter are deleted.
Regards, Krzysztof
4:32 p.m.
-----Original Message-----
From: Krzysztof Kosiński [mailto:tweenk.pl@...400...]
Sent: Friday, January 22, 2010 12:05
To: inkscape-devel
Subject: Re: [Inkscape-devel] Node tool committed to trunk
> *LPE: Switcher does not show with Knot LPE.
> Another LPE issue:
> it is no longer possible to edit parameters on-canvas, like
the points in LPE-Hatches.
It was actually the same issue - it should be fixed now.
The Knot LPE doesn't show the curved arrow around the point
yet, and the outline of the original path is always shown. I
guess there should be a flag that allows the effect to
specify whether it wants to always display the outline, or
only when the the "show outline" toggle button is on.
There is indeed a flag for that. See src/live_effects/effect.h, line 112.
I'm sorry for the mess in the LPE code. It used to be pretty clean, but after all the
additions, it really needs cleaning up. Unfortunately, my Inkscape-time is very limited.
:/
Cheers,
Johan
4:35 p.m.
-----Original Message-----
From: J.B.C.Engelen@...1578...
[mailto:J.B.C.Engelen@...1578...]
Sent: Friday, January 22, 2010 15:32
To: tweenk.pl@...400...; inkscape-devel(a)lists.sourceforge.net
Subject: Re: [Inkscape-devel] Node tool committed to trunk
> -----Original Message-----
> From: Krzysztof Kosiński [mailto:tweenk.pl@...400...]
> Sent: Friday, January 22, 2010 12:05
> To: inkscape-devel
> Subject: Re: [Inkscape-devel] Node tool committed to trunk
>
> > *LPE: Switcher does not show with Knot LPE.
>
> > Another LPE issue:
> > it is no longer possible to edit parameters on-canvas, like
> the points in LPE-Hatches.
>
> It was actually the same issue - it should be fixed now.
> The Knot LPE doesn't show the curved arrow around the point
yet, and
> the outline of the original path is always shown. I guess
there should
> be a flag that allows the effect to specify whether it
wants to always
> display the outline, or only when the the "show outline"
toggle button
> is on.
There is indeed a flag for that. See
src/live_effects/effect.h, line 112.
Sorry, I looked in wrong file. It should be line 110.
11:52 a.m.
can we have a windows build to test this tool on XP, and win 7 ?
2010/1/14 Krzysztof Kosiński <tweenk.pl@...400...>:
The new node tool is now in the trunk - please test and report any
bugs. I made a few last minute improvements inspired by the
discussion.
New features are listed in the release notes:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Node_Tool
I also made a new icon for the spray tool. It's much better than the
old one, but there's still something not quite right with it.
Regards, Krzysztof
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--
Nemes Ioan Sorin
2:05 p.m.
SorinN wrote:
can we have a windows build to test this tool on XP, and win 7 ?
+1
and thanks in advance,
Alvin Penner
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27188799.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
3:53 p.m.
On 14/1/10 19:40, Krzysztof Kosiński wrote:
The new node tool is now in the trunk - please test and report any
bugs. I made a few last minute improvements inspired by the
discussion.
New features are listed in the release notes:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.48#Node_Tool
moving back to a more appropriate thread about the new node tool...
On 16/1/10 12:07, Krzysztof Kosiński wrote:
W dniu 16 stycznia 2010 11:18 użytkownik ~suv
<suv-sf@...58...> napisał:
> > I'm not sure if all is good...
> >
> > I updated to revision 8988. Building went without any new errors besides
> > the known warnings.
> >
> > The new node tool is very unstable and unpredictable for me, and barely
> > usable in LPE effects to adjust effect parameters on-canvas precisely
> > [1] and when snapping is active (doesn't make a difference if snap delay
> > is default or reduced to 0ms). Since I haven't heard about this from
> > others - here, on the bug tracker or in #inkscape - I'm not sure if this
> > due to using gcc-4.0 to build Inkscape.
Try revision 8989, there was a very stupid bug in CurveDragPoint (it
could try to construct a Glib::ustring from NULL under certain
circumstances). It is not related to using __gnu_cxx or unordered_set.
So far I could not reproduce the crash with revision 8989 - I'll keep
trying ;) Meanwhile ...
... some other questions about the new node tool:
1) removing several cusp nodes e.g. of a default star converted to path:
With Inkscape 0.47 r22853 the nodes at the ends of the new (shortened)
straight segment are still cusp without any (new) handles.
With the new node tool the resulting new segment is curved i.e. it has
handles on both side with seemingly random angles and lengths. To me
this is an unexpected change of the path-segment.
2) tabbing through nodes, finding first/last node
In Inkscape 0.47 r22583 I could conveniently find the first node of a
path by selecting the path with the select tool, switch to the node tool
and <TAB> once for the first node (or Shift+<TAB> for the last) and
continue through all nodes with <TAB>.
With the new node tool this no longer works: now I have to select at
least one node of a sub-path and <TAB> goes from there. If by chance I
picked the last node I'm out of luck: the first <TAB> deselects all
nodes and neither a second <TAB> nor a Shift+<TAB> does allow me to
further select adjacent nodes of the sub-path.
3) editing LPEs with multiple path effect parameters on canvas
e.g. VonKoch has a reference segment and a generating path
In Inkscape 0.47 it was possible to edit both paths alternately with the
node tool by either using the button on the node tool controls bar to
cycle through all available path effect parameters or by clicking on the
node-edit tool in the path effect editor for each parameter.
Both methods fail with the new node tool: I can edit one parameter by
clicking the node-edit icon in the path effect editor, to edit the
second one I first have to change back to the select tool, then click on
the node-edit icon for the other parameter in the path effect editor.
The button on the node edit controls bar fails to switch parameters
while the node tool is active.
4) node transformation - snapping a selection of nodes
Snapping works for me only works when snapping individual nodes, but
fails with a selection of several nodes (doesn't matter if they are part
of the same sub-path, part of several sub-paths or part of different
paths).
Whenever snapping occurs while dragging or when releasing the mouse only
the selected node used for dragging snaps and changes its position in
relation to the other nodes i.e. the geometry of the selected portion of
the paths changes while dragging with snapping enabled. Changing snap
delay to 0ms doesn't improve or change this.
Please tell me if you'd prefer bug reports for any of above listed
issues instead of adding them to this thread.
~suv
2:10 a.m.
W dniu 16 stycznia 2010 14:53 użytkownik ~suv
<suv-sf@...58...> napisał:
Please tell me if you'd prefer bug reports for any of above
listed
issues instead of adding them to this thread.
No, bug reports won't be required. Thanks for reporting all issues,
I'm working on them.
Regards, Krzysztof
6:53 p.m.
On 16/1/10 14:53, ~suv wrote:
2) tabbing through nodes, finding first/last node
fixed in revision 9002
4) node transformation - snapping a selection of nodes
fixed in revision 9001
5) Now that snapping works for multiple selected nodes, I notice that
handles don't snap at all - unlike in Inkscape 0.47. This is not a new
issue - it didn't work prior to your recent fixes either.
Thank you very much for all your efforts!
~suv, :)
7:36 p.m.
It appears that Ctrl+Alt+Click to create/delete nodes didn't make
it
into the rewrite.
Fixed.
Middle click to zoom in does not work.
Fixed.
1) removing several cusp nodes e.g. of a default star converted to
path:
I have some doubts about "fixing" this. There are two actions:
delete
while preserving shape (Delete) and delete without preserving shape
(Control+Delete). Why should the first one cease to work when
operating on linear segments?
2) tabbing through nodes, finding first/last node
Partially
fixed: Tab selects the first node when nothing is selected.
I am not sure what exactly Tab should when operating on a path with
multiple subpaths, so there might be other issues.
4) node transformation - snapping a selection of nodes
Fixed.
The LPE issues are not fixed yet, I'm still figuring out the path effects API.
Regards, Krzysztof
7:42 p.m.
2010/1/20 Krzysztof Kosiński <tweenk.pl@...400...>:
> 2) tabbing through nodes, finding first/last node
Partially fixed: Tab selects the first node when nothing is selected.
I am not sure what exactly Tab should when operating on a path with
multiple subpaths, so there might be other issues.
See the code of the old node tool. It was all worked out: it traversed
nodes within one subpath, then jumped to the next subpath and
traversed it, then when there are no more subpath it went to the
beginning and started the cycle anew. Shift+tab cycled the other way
around.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
8:11 p.m.
W dniu 20 stycznia 2010 18:42 użytkownik bulia byak
<buliabyak@...400...> napisał:
See the code of the old node tool. It was all worked out: it
traversed
nodes within one subpath, then jumped to the next subpath and
traversed it, then when there are no more subpath it went to the
beginning and started the cycle anew. Shift+tab cycled the other way
around.
A-ha! I checked 0.47, and the first Tab selects only one node. I was
working under the assumption that it shifts the selection around. I'll
fix this shortly.
Regards, Krzysztof
9:49 p.m.
On Wed, 2010-01-20 at 18:36 +0100, Krzysztof Kosiński wrote:
> It appears that Ctrl+Alt+Click to create/delete nodes didn't
make it
> into the rewrite.
Fixed.
Not really. It still does not create them. Also, to delete them it seems
to want to cycle through nodes before it will delete (meaning I am doing
Ctrl+Alt+Click numerous times on a node before it goes away).
Cheers,
Josh
10:39 p.m.
W dniu 20 stycznia 2010 20:49 użytkownik Joshua A. Andler
<scislac@...400...> napisał:
Not really. It still does not create them. Also, to delete them it
seems
to want to cycle through nodes before it will delete (meaning I am doing
Ctrl+Alt+Click numerous times on a node before it goes away).
Creating with Ctrl+Alt+click now works (rev 9007). I can't reproduce
the Ctrl+Alt problem. If you want to investigate, the mouse click
event is handled in PathManipulator::_nodeClicked at
ui/tool/path-manipulator.cpp:1180.
Regards, Krzysztof
11:18 p.m.
On Wed, 2010-01-20 at 21:39 +0100, Krzysztof Kosiński wrote:
W dniu 20 stycznia 2010 20:49 użytkownik Joshua A. Andler
<scislac@...400...> napisał:
> Not really. It still does not create them. Also, to delete them it seems
> to want to cycle through nodes before it will delete (meaning I am doing
> Ctrl+Alt+Click numerous times on a node before it goes away).
Creating with Ctrl+Alt+click now works (rev 9007). I can't reproduce
the Ctrl+Alt problem. If you want to investigate, the mouse click
event is handled in PathManipulator::_nodeClicked at
ui/tool/path-manipulator.cpp:1180.
Yay, thanks for fixing that.
A very easy way to reproduce the delete problem is to create a
Rectangle, convert to path, Ctrl+Alt+Click on any of the corner nodes.
Cheers,
Josh
12:09 a.m.
W dniu 20 stycznia 2010 22:18 użytkownik Joshua A. Andler
<scislac@...400...> napisał:
Yay, thanks for fixing that.
A very easy way to reproduce the delete problem is to create a
Rectangle, convert to path, Ctrl+Alt+Click on any of the corner nodes.
I am doing just this, and they delete fine. Does Alt work at all?
(e.g. try dragging a node with extended handles with Ctrl+Alt, if it's
constrained to handle lines, then Alt works; if it is constrained to
axes, then it doesn't work).
There was a slightly different issue though: when transform handles
were enabled, Ctrl+Alt+click didn't work on selected nodes. It's fixed
in rev. 9008.
Regards, Krzysztof
4 p.m.
Under Windows XP, latest build (bzr 9010): ctrl modifier does work for node
type change when single clicking but doesn't for axis constraint movements
of nodes in a path when in node tool (F2).
I also tried ctrl-alt click to add and remove nodes: it works.
But when I remove a node between two segments (I mean straight segments of a
path) I would expect the single line to remain a segment while now it's
turned into a curved line. This happens both with ctrl-alt click and using
delete and is different from the old behavior. It's very annoying for who,
like me, usually draws only straight segments (technical drawing): I always
have to reconvert the segment back to straight. Also, I can't see the point
in doing in this way: if you really need this you are probably already
working with curves so you don't need to do anything before removing the
node; otherwise I feel it's acceptable to convert the two segments to curves
before deleting the node as this behavior is not consistent with the
starting shape of the path.
I didn't explain it very well, I hope it's understandable. :)
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27258196.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:14 p.m.
Actually no modifier is doing anything for me while dragging nodes.
And I realized that ctrl-canc does what I was looking for: why have canc
(del) and ctrl-canc (ctrl-del) been swapped? I don't think the current
behavior is intuitive. And also, I was used to the old one! :)
Another consideration: double clicking already adds a node (it's the same as
ctrl-alt click) so, won't it be more intuitive to have ctrl double clicking
delete an existing node rather than introducing new double-modifiers (one of
which is a duplicate of something already implemented)?
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27258409.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:44 p.m.
I read more carefully this thread and found that this issue had already been
reported.
> 1) removing several cusp nodes e.g. of a default star converted
to path:
I have some doubts about "fixing" this. There are two actions: delete
while preserving shape (Delete) and delete without preserving shape
(Control+Delete). Why should the first one cease to work when
operating on linear segments?
Well, it depends on what you think "preserving shape" does mean: to me it
means that a straight line should remain a straight line.
Try drawing a single straight segment, then ctrl-alt click to add a node
inside it then press canc: you get the original segment that has been turned
into a (straight) curve. I don't think this can be said to be preserving the
shape.
In conclusion, I think that if a path is straight-segmented, preserving its
shape means keeping its segments straight while turning them into curves is
changing its shape. So, under this assumption the old behavior was correct
and the new one is not.
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27258855.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
6:33 p.m.
Ctrl-dragging nodes is still not working for me (Windows XP): I can freely
move the node also when pressing ctrl but it snaps correctly if, for
example, it finds a guide (but not always).
And in some cases I see the snap indicator near the pointer but the node
doesn't leave its initial position neither it snaps where expected when
releasing the mouse button.
Regards.
Luca
--
View this message in context:
http://old.nabble.com/Node-tool-committed-to-trunk-tp27166170p27374542.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
2:49 a.m.
2010/1/29 LucaDC <dicappello@...2144...>:
Ctrl-dragging nodes is still not working for me (Windows XP): I can freely
move the node also when pressing ctrl but it snaps correctly if, for
example, it finds a guide (but not always).
And in some cases I see the snap indicator near the pointer but the node
doesn't leave its initial position neither it snaps where expected when
releasing the mouse button.
Constrained dragging was indeed completely broken, because I
misunderstood the snapping API. It should be fixed in r9035.
For any remaining problems, please open bug reports and assign me to
them - this thread has grown rather large and I have some difficulty
keeping track of what is fixed and what isn't yet.
Regards, Krzysztof
4739
days inactive
4761
days old
inkscape-devel@lists.inkscape.org
45 comments
10 participants
participants (10)
-
unknown＠example.com -
Alvin Penner -
bulia byak -
Jasper van de Gronde -
Joshua A. Andler -
Krzysztof Kosiński -
LucaDC -
Maximilian Albert -
SorinN -
~suv