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
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
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?
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
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
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
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.
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?
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
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
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
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
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
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
-----Original Message----- From: LucaDC [mailto:dicappello@...2144...] Sent: vrijdag 22 januari 2010 18:38 To: inkscape-devel@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
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
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.
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
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
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
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
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.
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-VonKoch.html
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
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
-----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.
*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
-----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
-----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@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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
SorinN wrote:
can we have a windows build to test this tool on XP, and win 7 ?
+1
and thanks in advance, Alvin Penner
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
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
On 16/1/10 14:53, ~suv wrote:
- tabbing through nodes, finding first/last node
fixed in revision 9002
- 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, :)
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.
- 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?
- 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.
- 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
2010/1/20 Krzysztof Kosiński <tweenk.pl@...400...>:
- 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.
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
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
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
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
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
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
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
I read more carefully this thread and found that this issue had already been reported.
- 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
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
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
participants (10)
-
unknown＠example.com -
Alvin Penner -
bulia byak -
Jasper van de Gronde -
Joshua A. Andler -
Krzysztof Kosiński -
LucaDC -
Maximilian Albert -
SorinN -
~suv