Krzysztof,
I finally found time to test the new node tool. Overall it feels great, but of course I found many small and not so small things to fix :) #1 is my personal pet peeve, if you can't see it please just give me pointers to the code which passes events up and I'll have a look myself.
I'll probably have more as I do more testing, but here's the fist batch:
1. Bug: Middle-button dragging and Shift-middle button zoom rubberband still do not work. Are you using a mouse with a middle button to test? They work in Selector but not in Node.
2. Lost feature: when rotating/scaling nodes by keys and one node is mouseovered, it is used as center of rotation and scaling.
3. Lost feature: when ctrl+alt+dragging a node, it should slide along the handles _and their perpendiculars_.
4. Lost feature: when ctrl+alt+dragging a node, and it has a linear segment on one side, it should slide along the continuation of that segment.
5. Lost feature: node sculpting. Will you work on it, or do you want me to work on porting it?
6. Bug: select a single node and rotate it by [] with or without Alt: it rotates around some random center far away, instead of around itself.
7. Lost feature: When rotating a handle with Ctrl, it now snaps to the original position and 15 deg increments from that original position. The previous behaviour was: snap to origin, its opposite and perpendicular, to vertical/horizontal, and to 15 deg steps from vertical. This is much more useful because more often, I use Ctrl to snap it to vertical or some simple angle like 60 deg.
8. Lost feature: create a cusp node next to a linear segment; press Shift+S; it becomes semismooth, aligned with the segment (correct); now press Shift+S again; old behavior is to make it fully smooth, extending the second handle, but your tool does nothing.
9. Lost feature: Rotating a handle with Shift before allowed to rotate the second handle by the same angle, thus rotating a cusp node as a whole; now it does nothing.
10. Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing selected should do the same in Node tool as in Selector, instead of doing nothing as now.
11. Performance: Create a path with thousands of nodes (paste text, convert to path, combine), select it in Node tool: notice how slow it all becomes, freezing for many seconds, as you simply move your mouse over the path. My guess is that it calculates something on each motion event and does not cache the results. The old tool also wasn't very snappy in such situation but it was much better, only freezing for a couple seconds at most with the same file (test it!) partly because it cached the livarot representation of the path it used for proximity/over the path calculations.
12. Lost feature: the statusbar used to say how much total nodes are there ("2 of 5 nodes selected") and, for a single node, its type (smooth, cusp, auto). For multiple subpaths it said e.g. "2 of 9 nodes selected in 2 of 3 subpaths". Now it only says "Selected 2 nodes" (which is also a wrong word order, suggesting an action instead of a state). Could you please just copy this part from the old node tool?
13. Suggested feature: now that we can select multiple objects, the statusbar hints must reflect that, in the same way as subpaths, e.g. "2 of 9 nodes selected in 2 of 3 subpaths in 1 of 2 selected paths", or simply "2 of 9 nodes selected in 1 of 2 selected paths" if there are no subpaths involved.
14. Bug: when dragging a node handle, statusbar erroneously says "Move by" instead of "Node handle:" as did the old tool.
15. When mouseovering a node, it says "click to select" even if it is already selected. I'd like to copy this from the old tool as well, which suggested various modifiers for dragging instead.
16. On the node deletion discussion, I found the current behavior satisfactory: if you Del, you get curved approximation; if you Ctrl+del you get linear segment from linears. I think this is logical (unless I miss something).
17. UI suggestion: since the show/hide seltrans handles button belongs to visualization, it should be moved to the right end of the controls bar, next to node handles and node outline toggles.
18. Crash: draw a path; draw a path and apply it as mask; draw another and apply as clippath; go to node tool; enable both mask and clippath editing; drag a mask node; drag a clippath node; drag a node of the path itself; undo 4 times - crash.
19. UI bug: create with Pen a Spiro path; now switch to Node tool - the green outline of the source path is visible always, even when "show outline of path" toggle is off and "show path parameter" was never pressed. Also, as we discussed in the summer, I suggested a purple color for LPE parameter paths, so they are not confused with clippaths.
20. Crash (somewhat hard to reproduce): With Pencil in Spiro mode, create a path with just two nodes (click, click). Now create a curved doodle path (unrelated bug in Pencil: you need to deselect first path before drawing second, otherwise they will become joined!). Now select both paths, go to Node. Select the end node of the linear path and start node of the curved path. Mouseover the latter and press Shift+J. Then press Ctrl+Z while still mouseovering the joined node. Crash:
Program received signal SIGSEGV, Segmentation fault. Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060 1060 { (gdb) bt #0 Inkscape::UI::NodeList::closed (this=0xbfffe3dc) at ui/tool/node.cpp:1060 #1 0x085fc574 in Inkscape::UI::CurveDragPoint::_getTip (this=0xb8d57c8, state=4) at ui/tool/curve-drag-point.cpp:152 #2 0x085fadc1 in Inkscape::UI::ControlPoint::_updateTip (this=0xb8d5790, state=4) at ui/tool/control-point.cpp:470 #3 0x085fb914 in Inkscape::UI::ControlPoint::_setMouseover (p=0xb8d5790, state=4) at ui/tool/control-point.cpp:460 #4 0x085fc122 in Inkscape::UI::ControlPoint::_eventHandler (this=0xb8d5790, event=0xaf56a80) at ui/tool/control-point.cpp:411 #5 0x085faad8 in Inkscape::UI::ControlPoint::_event_handler (event=0xaf56a80, point=0xb8d5790) at ui/tool/control-point.cpp:298 #6 0x0824dd28 in sp_marshal_BOOLEAN__POINTER (closure=0xb5c0270, return_value=0xbfffe80c, n_param_values=2, param_values=0xad41600, invocation_hint=0xbfffe6b0, marshal_data=0x85faac0) at helper/sp-marshal.cpp:352 #7 0x0056a072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #8 0x0057f7a8 in ?? () from /usr/lib/libgobject-2.0.so.0 #9 0x005809b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #10 0x012b38ee in gtk_signal_emit () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x081c66df in emit_event (canvas=<value optimized out>, event=0xb8d57c8) at display/sp-canvas.cpp:1348 #12 0x081c68e3 in pick_current_item (canvas=0x985c060, event=<value optimized out>) at display/sp-canvas.cpp:1491 #13 0x081c9431 in sp_canvas_motion (widget=0x985c060, event=0xaf58340) at display/sp-canvas.cpp:1603
bulia byak wrote:
- On the node deletion discussion, I found the current behavior
satisfactory: if you Del, you get curved approximation; if you Ctrl+del you get linear segment from linears. I think this is logical (unless I miss something).
Well, it may be defined "logical" but with reference to which "logic"? Now if you del a node aligned with its neighbours you get a "straight curve" also if it wouldn't be strictly (i.e. mathematically, or geometrically if you prefer: theese are other examples of "logic" that could be applied but I could mention graphic, aesthetic, practicity, ergonomics, ...) needed. That is, when deleting a node its sides are _always_ converted to curves. Probably Inkscape doesn't like segments at all... ;) In my head, if I set a node as cusp or as smooth, I expect this property to be preserved while I manipulate my path unless I explicitly change it, or I make an operation that indirectly, and with no ambiguity, requires the change to be aplied. Anyway, should I assume this as a stop point or is there space for further discussion? If this is really the last word, I will simply stick to 0.47: having to press ctrl-del every time in my daily work is too penalizing for me.
Regards. Luca
On Mon, Feb 8, 2010 at 7:26 AM, LucaDC <dicappello@...2144...> wrote:
Well, it may be defined "logical" but with reference to which "logic"? Now if you del a node aligned with its neighbours you get a "straight curve" also if it wouldn't be strictly (i.e. mathematically, or geometrically if you prefer: theese are other examples of "logic" that could be applied but I could mention graphic, aesthetic, practicity, ergonomics, ...) needed.
This is a reasonable improvement request: if the standard approximating algorithm produces a straight line, make it a linear segment without handles. I think we should do this.
Anyway, should I assume this as a stop point or is there space for further discussion? If this is really the last word, I will simply stick to 0.47: having to press ctrl-del every time in my daily work is too penalizing for me.
Will the above suggestion - do not extend handles if there's no curvilinearity in the result - work for you?
Here's an example of situation where the current behavior is better: imagine a curve is approximated by a number of short segments, some or all of which are linear. Now I can easily delete all inside nodes and get a single-Bezier approximation of that curve. It's not so uncommon in artistic uses of the program.
LucaDC wrote:
bulia byak wrote:
- On the node deletion discussion, I found the current behavior
satisfactory: if you Del, you get curved approximation; if you Ctrl+del you get linear segment from linears. I think this is logical (unless I miss something).
Well, it may be defined "logical" but with reference to which "logic"? Now if you del a node aligned with its neighbours you get a "straight curve" also if it wouldn't be strictly (i.e. mathematically, or geometrically if you prefer: theese are other examples of "logic" that could be applied but I could mention graphic, aesthetic, practicity, ergonomics, ...) needed. That is, when deleting a node its sides are _always_ converted to curves. Probably Inkscape doesn't like segments at all... ;) In my head, if I set a node as cusp or as smooth, I expect this property to be preserved while I manipulate my path unless I explicitly change it, or I make an operation that indirectly, and with no ambiguity, requires the change to be aplied. Anyway, should I assume this as a stop point or is there space for further discussion? If this is really the last word, I will simply stick to 0.47: having to press ctrl-del every time in my daily work is too penalizing for me.
I'd like to second that. Working with straight segments vs. working with curves is fundamentally different. Currently when I draw two STRAIGHT segments (no handles, cusp nodes) and delete the middle node it suddenly turns my two straight segments into one curved shape... So I would like to reiterate the previously-mentioned solution:
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
This way delete would normally try to preserve the shape while mostly respecting the user's choices (a node without handles would remain a node without handles, a smooth node would remain a smooth node, a symmetric node would remain symmetric). One could argue about the extent to which the handles of a smooth or symmetric node would be allowed to change (that is, whether the change is allowed to affect neighbouring segments). But in general this should be fine.
Shift+Del would correspond to simply removing the one node and ignoring what it does to the shape. Could be useful whenever the handles are sacred. (Although I have my doubts about its usefulness if Del would make sure that handles of neighbouring segments remain unchanged.)
Ctrl+Del would be the ultimate tool for people who are not so much concerned about handles and such but only in the rough shape of the object. In fact, you could even consider letting Ctrl+Del move (neighbouring?) nodes if it will help in preserving the shape (a kind of local simplify).
bulia byak wrote:
This is a reasonable improvement request: if the standard approximating algorithm produces a straight line, make it a linear segment without handles. I think we should do this.
Will the above suggestion - do not extend handles if there's no curvilinearity in the result - work for you?
Unfortunately not. What I (only me?) need is the old behaviour so when you delete a node from a rectangle it becomes a triangle. Now the _only_ way to have this (which I consider a very intuitive and expected result) is using ctrl-del. With the current behaviour the curvilinearity is forced even if it's not present in the starting object (as happens for a rectangle), so the case where it's both present at the beginning and at the end is trivial and I'm not concerned with it; it was only an example on how the currently implemented "interpretation" can degenerate.
bulia byak wrote:
Here's an example of situation where the current behavior is better: imagine a curve is approximated by a number of short segments, some or all of which are linear. Now I can easily delete all inside nodes and get a single-Bezier approximation of that curve. It's not so uncommon in artistic uses of the program.
This can easily be achieved simply by converting all short segments to curves (only one drag-select and convert-button-click operation); now you can remove the unwanted nodes. There's no need to change the default del behaviour. And also, the context is that you are working with curves (also if approximated), not with segments! So it's reasonable that you want to get rid of segments having an easy way to get a "real" curve from them. On the other hand, when you work with segments you need exactly the opposite, that is segments that stay segments. It's a completely different scenario. And also, the approximated curve probably comes from an external application: I don't think someone would draw a huge amount of small segments to eventually convert them to a curve. But when I'm drawing and using segments it's because I _want_ to work with segments, so there's an explicit operation from the user. I wouldn't discard properties explicitly set by the user if not explicitly asked for; and simply deleting a node can't be considered as an explicit request. An example: you have a folder with all your photos named 'photo0001', 'photo0002', ... up to 'photo0254'. 'photo0127' is really ugly so you delete it and automatically you have all other files renamed to -1 by your super-clever OS (!) so 'photo0128' is now 'photo0127' and 'photo0254' is 'photo0253', so there are no "numeric holes". Logical, isn't it? You see that 'photo0127' still exist and try to delete again, again and again till it's deleted (and all up to 'photo254' with it... Hey, didn't you read the OS's manual before deleting a file? :). Or you had old 'photo0202' as desktop background and suddenly get old 'photo0203'. Or a month later a friend of yours asks for 'photo0192' that she loved so much but she's lost it (pity you didn't take a look before sending and that in old 'photo0193' there was another girl... ;). Did you ask for the automagical rename when deleting? Did you need it? Did you _want_ it?
Regards. Luca
2010/2/8 LucaDC <dicappello@...2144...>:
This can easily be achieved simply by converting all short segments to curves (only one drag-select and convert-button-click operation); now you can remove the unwanted nodes.
The problem is not what can be achieved, but whether it's consistent and logical for new users. Previously Del would sometimes fit a Bezier and sometimes not, and if it didn't there was no way to convince it otherwise. Now Del always fits a Bezier, and Ctrl+Del always places a linear segment. We're just asking you to be explicit and say whether you want to fit a Bezier to the removed nodes or not. By the way, deleting multiple linear segments and obtaining a Bezier approximation of them was completely impossible before.
Your problem boils down to Ctrl+Del being inconvenient on some keyboards. What about adding the keybindings of both delete actions to keys.xml? You could then assign them to any keys you like. We could also try to find a better default shortcut.
We can also add another checkbox: "invert fit behavior for linear segments", but I would like to avoid this if possible.
On the other hand, when you work with segments you need exactly the opposite, that is segments that stay segments. It's a completely different scenario.
Your perspective is that Bezier segments are very different from linear segments. However, other features of the tool don't suggest this: dragging out handles, retracting them, changing node types, etc. all change the type of the segment.
And also, the approximated curve probably comes from an external application: I don't think someone would draw a huge amount of small segments to eventually convert them to a curve.
My friend works like this all the time. He manually traces photos by zooming in and drawing polylines using the pen tool. The "delete with fit" behavior for linear segments would allow him to smooth out the drawing with more precision than the Simplify action (important when the traced object has distinct cusps).
Did you ask for the automagical rename when deleting? Did you need it? Did you _want_ it?
I see no connection between this example and the Delete key behavior. A better example that illustrates the old behavior would be responding to deleting files by moving a file to trash when it's in your home folder but deleting it when it's outside it (like on external drives or in system folders). The new behavior is like always moving files to trash with Del, and always removing files completely with Shift+Del. (BTW changing from Ctrl+Del to Shift+Del might make sense, because of this OS-related association.)
Regards, Krzysztof
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>:
2010/2/8 LucaDC <dicappello@...2144...>:
This can easily be achieved simply by converting all short segments to curves (only one drag-select and convert-button-click operation); now you can remove the unwanted nodes.
The problem is not what can be achieved, but whether it's consistent and logical for new users. Previously Del would sometimes fit a Bezier and sometimes not, and if it didn't there was no way to convince it otherwise. Now Del always fits a Bezier, and Ctrl+Del always places a linear segment.
I don't think this is the kind of consistency we're trying to achieve. A linear segment without handles is still a special case of Bezier, after all. Better don't think in terms of beziers/nonbeziers at all, and put it this way: Del produces an approximation (whatever that may be), and Ctrl+del does not.
And in case of three line-aligned nodes and Del-eting the middle one, I really think we must not extend any handles. It won't be inconsistency - simply in this case, a linear segment *is* the best approximation, so we do not do any special-casing here.
We can also add another checkbox: "invert fit behavior for linear segments", but I would like to avoid this if possible.
As I wrote, just make it "swap behavior of Del and Ctrl+Del" - easier to understand and describe in the docs.
On Mon, Feb 8, 2010 at 10:54 AM, LucaDC <dicappello@...2144...> wrote:
Will the above suggestion - do not extend handles if there's no curvilinearity in the result - work for you?
Unfortunately not. What I (only me?) need is the old behaviour so when you delete a node from a rectangle it becomes a triangle. Now the _only_ way to have this (which I consider a very intuitive and expected result) is using ctrl-del.
But it's still possible, by only one extra key :)
I'm not trying to imply that your usage scenarios are not realistic. They are. I'm just trying to show that the other scenarios are realistic too. Inkscape, with its wonderful "yes you can" mindset, has accommodated both, and it is just so happened historically that one way of use requires a modifier while the other does not. Deciding now that their order of importance is wrong and swapping that modifier would be a very weird thing to do - for Inkscape as a project. However, for a specific user it would be natural, and as much as I hate adding prefs, I would not object to placing a "Swap behavior of Del and Ctrl+Del" checkbox in Node tool prefs. Will that work for you (and others)?
An example: you have a folder with all your photos named 'photo0001', 'photo0002', ... up to 'photo0254'. 'photo0127' is really ugly so you delete it and automatically you have all other files renamed to -1 by your super-clever OS (!) so 'photo0128' is now 'photo0127' and 'photo0254' is 'photo0253', so there are no "numeric holes". Logical, isn't it?
This is actually a very good example for understanding our different approaches. For you, each of these files is a unique photo that you want to keep its unique name and place. But for me, they are just *frames in a movie*, and when I delete some single frames, I would really like my video editor to shift and interpolate all other frames in order to avoid jerks and keep correct timing. I don't even care that some of the automatically interpolated frames would look a bit weird - at 25 frames a second this won't be noticeable.
See? You do photography, I do video. Both are valid uses of Inkscape :)
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Monday, February 08, 2010 17:04 To: LucaDC Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] node tool testing
On Mon, Feb 8, 2010 at 10:54 AM, LucaDC <dicappello@...2144...> wrote:
Will the above suggestion - do not extend handles if there's no curvilinearity in the result - work for you?
Unfortunately not. What I (only me?) need is the old
behaviour so when
you delete a node from a rectangle it becomes a triangle. Now the _only_ way to have this (which I consider a very intuitive and expected result) is using ctrl-del.
But it's still possible, by only one extra key :)
I'm not trying to imply that your usage scenarios are not realistic. They are. I'm just trying to show that the other scenarios are realistic too. Inkscape, with its wonderful "yes you can" mindset, has accommodated both, and it is just so happened historically that one way of use requires a modifier while the other does not. Deciding now that their order of importance is wrong and swapping that modifier would be a very weird thing to do - for Inkscape as a project. However, for a specific user it would be natural, and as much as I hate adding prefs, I would not object to placing a "Swap behavior of Del and Ctrl+Del" checkbox in Node tool prefs. Will that work for you (and others)?
Historically, rectangle->triangle deletion was implemented first, and has been under the normal delete button without modifier for quite a while. Now in trunk we got an added feature of deletion while 'maintaining' shape. Since it has not been released yet, there is no real history of having both features, so the discussion on which one is most important isn't very weird to me. I understand that different people have different preferences, but changing behavior from one version to the next should be for a good reason. A preference setting would work for me. I vote for the default setting to be 0.47 behaviour. New users won't know that there is a way to change the Del behaviour; with 'maintain shape' as default I think all people I know will scream and run back to whatever program they used before ;)
Ciao, Johan
Sent from my iPhone
On 9 Feb 2010, at 09:24, <J.B.C.Engelen@...1578...> wrote:
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Monday, February 08, 2010 17:04 To: LucaDC Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] node tool testing
On Mon, Feb 8, 2010 at 10:54 AM, LucaDC <dicappello@...2144...> wrote:
Will the above suggestion - do not extend handles if there's no curvilinearity in the result - work for you?
Unfortunately not. What I (only me?) need is the old
behaviour so when
you delete a node from a rectangle it becomes a triangle. Now the _only_ way to have this (which I consider a very intuitive and expected result) is using ctrl-del.
But it's still possible, by only one extra key :)
I'm not trying to imply that your usage scenarios are not realistic. They are. I'm just trying to show that the other scenarios are realistic too. Inkscape, with its wonderful "yes you can" mindset, has accommodated both, and it is just so happened historically that one way of use requires a modifier while the other does not. Deciding now that their order of importance is wrong and swapping that modifier would be a very weird thing to do - for Inkscape as a project. However, for a specific user it would be natural, and as much as I hate adding prefs, I would not object to placing a "Swap behavior of Del and Ctrl+Del" checkbox in Node tool prefs. Will that work for you (and others)?
Historically, rectangle->triangle deletion was implemented first, and has been under the normal delete button without modifier for quite a while. Now in trunk we got an added feature of deletion while 'maintaining' shape. Since it has not been released yet, there is no real history of having both features, so the discussion on which one is most important isn't very weird to me. I understand that different people have different preferences, but changing behavior from one version to the next should be for a good reason. A preference setting would work for me. I vote for the default setting to be 0.47 behaviour. New users won't know that there is a way to change the Del behaviour; with 'maintain shape' as default I think all people I know will scream and run back to whatever program they used before ;)
Ciao, Johan
It probably invalidates a bunch of tutorials too, fairly sure Ive used a create this shape delete this node approach at least once.
The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Feb 9, 2010 at 5:24 AM, <J.B.C.Engelen@...1578...> wrote:
Historically, rectangle->triangle deletion was implemented first, and has been under the normal delete button without modifier for quite a while.
Yes but:
Now in trunk we got an added feature of deletion while 'maintaining' shape.
no, this behavior is very old too, it was added in 0.44:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.44#New_deletion_beha...
and has been the default since.
What changed in the trunk is just one special case of this, making this behavior more general and consistent, not relying on the unreliable status of the segment. Just think: with handle of 0px you get one behavior, with handle of 0.000001px you get a quite different behavior - that can't be right!
And since it turned out that some users in fact have been relying on this inconsistency, we are giving them a preference switch, by using which they will be able to always (again, independently of any microscopic handles!) get the no-approximation behavior on Del. For them it should work even better than before.
Any other objections to the current behavior plus swapping preference?
bulia byak wrote:
Any other objections to the current behavior plus swapping preference?
Yes, both from you:
bulia byak wrote:
Inkscape, with its wonderful "yes you can" mindset, has accommodated both, and it is just so happened historically that one way of use requires a modifier while the other does not. Deciding now that their order of importance is wrong and swapping that modifier would be a very weird thing to do - for Inkscape as a project.
And you are swapping.
bulia byak wrote:
The old behavior was not consistent with selector tool and node transforms. All other constrained rotations snap to 15 deg increments from the original position. It is possible to make a handle horizontal by retracting it and then dragging it out with Shift+Ctrl.
Too much consistency may be bad sometimes.
I agree with you.
If you give me a preference to set and forget, that may be fine. I've already changed and stored so many preferences different than the default ones that one more will not hurt me.
Anyway I still consider this approach conceptually wrong as it's not up to Inkscape's programmers to decide what users should expect when pressing del. So many other programs already exibit a well known behaviour: why should Inkscape introduce a new one? Which clear and wide-accepted improvement does this add?
Regards Luca
P.S.: don't speak about zero length handlers, please, because a segment doesn't have handlers; a curve with a 0 length handler is a straight curve, not a segment; a curve with 0.00001 length handler is an "almost straight" curve, not a "quasi-segment". If you can't understand this you will probably never understand what we are speaking about.
On Tue, Feb 9, 2010 at 1:16 PM, LucaDC <dicappello@...2144...> wrote:
Inkscape, with its wonderful "yes you can" mindset, has accommodated both, and it is just so happened historically that one way of use requires a modifier while the other does not. Deciding now that their order of importance is wrong and swapping that modifier would be a very weird thing to do - for Inkscape as a project.
And you are swapping.
No we don't. We give you a way to swap them if you so prefer.
Too much consistency may be bad sometimes.
I agree with you.
This is not about consistency. It's about accommodating different usage scenarios.
If you give me a preference to set and forget, that may be fine.
OK, so I count you as support :) Any other objectors?
Anyway I still consider this approach conceptually wrong as it's not up to Inkscape's programmers to decide what users should expect when pressing del.
This is a philosophical argument, but I still disagree. We do this *all the time*, and in other cases you likely make a lot of use of our "deciding for you". There's no clear-cut line between being smart and "too smart". We're always trying to be smart and anticipate the needs of users. It's just that in this case, we anticipated the needs of other users, not you - but now we're fixing it so you can easily use it as well :)
So many other programs already exibit a well known behaviour: why should Inkscape introduce a new one? Which clear and wide-accepted improvement does this add?
This has been discussed to death, I don't think we should go start a new cycle :)
P.S.: don't speak about zero length handlers, please, because a segment doesn't have handlers; a curve with a 0 length handler is a straight curve, not a segment; a curve with 0.00001 length handler is an "almost straight" curve, not a "quasi-segment". If you can't understand this you will probably never understand what we are speaking about.
I understand perfectly. And I have been hit many times by inexplicable stupidity of Inkscape and other programs which change behavior in drastic ways in response to accidental, unnoticed by the user, changes somewhere. In Inkscape, we're trying to eliminate such weirdness and make the continuum of behaviors smoothly differentiable (if you understand what I mean :)
On Tue, 2010-02-09 at 09:16 -0800, LucaDC wrote:
Anyway I still consider this approach conceptually wrong as it's not up to Inkscape's programmers to decide what users should expect when pressing del. So many other programs already exibit a well known behaviour: why should Inkscape introduce a new one? Which clear and wide-accepted improvement does this add?
First off, there are plenty of things that Inkscape does differently than other applications due to programmer/developer decisions... sometimes users like those decision, other times they don't.
Just curious, did you read what bulia linked to in the release notes from 0.44? To me, it is direct and explicit and makes it seem like the new behavior perfectly fits that description... it was just an oversight by the developer who added the feature at that time wrt this one case. Anyway, if we have an option for behavior everyone wins.
Cheers, Josh
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Tuesday, February 09, 2010 16:16 To: Engelen, J.B.C. (Johan) Cc: dicappello@...2144...; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] node tool testing
On Tue, Feb 9, 2010 at 5:24 AM, <J.B.C.Engelen@...1578...> wrote:
Historically, rectangle->triangle deletion was implemented
first, and
has been under the normal delete button without modifier
for quite a
while.
Yes but:
Now in trunk we got an added feature of deletion while
'maintaining'
shape.
no, this behavior is very old too, it was added in 0.44:
http://wiki.inkscape.org/wiki/index.php/Release_notes/0.44#New
_deletion_behavior
and has been the default since.
This is a surprise. Sorry for the misinformation.
What changed in the trunk is just one special case of this, making this behavior more general and consistent, not relying on the unreliable status of the segment. Just think: with handle of 0px you get one behavior, with handle of 0.000001px you get a quite different behavior - that can't be right!
And since it turned out that some users in fact have been relying on this inconsistency, we are giving them a preference switch, by using which they will be able to always (again, independently of any microscopic handles!) get the no-approximation behavior on Del. For them it should work even better than before.
Any other objections to the current behavior plus swapping preference?
When deleting a node from an all-smooth path, two nodes are converted to cusp nodes. I actually thought this was a bug first; it is super annoying. But apparently this is desired behaviour for some users. So no objections anymore, and big thanks for the swap preference!!!
-johan
LucaDC wrote:
Unfortunately not. What I (only me?) need is the old behaviour so when you delete a node from a rectangle it becomes a triangle. Now the _only_ way to have this (which I consider a very intuitive and expected result) is using ctrl-del.
FWIW, the other two apps I could test Illustrator CS4 and Canvas X behave in this way by default.
Consider this another vote for keeping the old default behavior. The node tool, almost by definition, is for making fine tweaks and adjustments to a path. Therefore, I don't want Inkscape trying to guess what that path should look like. If I tell it to delete a node I expect it to delete the node while making the minimum possible changes to adjacent nodes.
Jasper van de Gronde wrote:
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
This seems like a reasonable solution.
Best,
Jed
W dniu 8 lutego 2010 04:48 użytkownik bulia byak <buliabyak@...400...> napisał:
Krzysztof,
I finally found time to test the new node tool. Overall it feels great, but of course I found many small and not so small things to fix :) #1 is my personal pet peeve, if you can't see it please just give me pointers to the code which passes events up and I'll have a look myself.
Thanks for all those tests. The code that handles events going to the canvas is in ui/tool/selector.cpp, but see below.
- Bug: Middle-button dragging and Shift-middle button zoom rubberband
still do not work. Are you using a mouse with a middle button to test? They work in Selector but not in Node.
Which revision are you using? For me (r9066 of trunk) they work correctly.
- Lost feature: node sculpting. Will you work on it, or do you want
me to work on porting it?
I will port it, but for now only one "sculpting profile" will be available. I would like to add enum support to preferences before introducing even more magic numbers to it.
- Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The previous behaviour was: snap to origin, its opposite and perpendicular, to vertical/horizontal, and to 15 deg steps from vertical. This is much more useful because more often, I use Ctrl to snap it to vertical or some simple angle like 60 deg.
The old behavior was not consistent with selector tool and node transforms. All other constrained rotations snap to 15 deg increments from the original position. It is possible to make a handle horizontal by retracting it and then dragging it out with Shift+Ctrl.
- Performance:
I fixed this recently (r9061). There were two issues: 1. libsigc++ is much slower than I expected, 2. I wasn't dropping motion events when there were many of them in the queue. Right now the performance should be comparable to 0.47, though probably further improvements are possible.
- When mouseovering a node, it says "click to select" even if it is already
selected. I'd like to copy this from the old tool as well, which suggested various modifiers for dragging instead.
I reused the GIMP paradigm of only showing the modifier tips when the relevant modifiers are pressed. This way the tip has some chance of being displayed in its entirety, especially on smaller screens. I can add a note like "(more: Shift, Ctrl, Alt)" at the end to make the modifier actions more discoverable.
- UI suggestion: since the show/hide seltrans handles button belongs
to visualization, it should be moved to the right end of the controls bar, next to node handles and node outline toggles.
There is a very important difference in behavior when transform handles are on: clicking on a selected node switches between rotation and scaling (consistent with selector) instead of making it the only one selected. This is the reason behind putting the button in front of the controls bar.
The rest of points are valid and I'll start working on them right away.
Regards, Krzysztof
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 8 lutego 2010 04:48 użytkownik bulia byak <buliabyak@...400...> napisał: Thanks for all those tests. The code that handles events going to the canvas is in ui/tool/selector.cpp, but see below.
OK, looks like I'll have to dig into it, as it still doesn't work in 9066.
- Lost feature: node sculpting. Will you work on it, or do you want
me to work on porting it?
I will port it, but for now only one "sculpting profile" will be available. I would like to add enum support to preferences before introducing even more magic numbers to it.
Thanks! Actually as I remember the other profiles were more or less placeholders in the old code too, I intended to enable them in UI one day, but for now only bell-shape worked.
- Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The previous behaviour was: snap to origin, its opposite and perpendicular, to vertical/horizontal, and to 15 deg steps from vertical. This is much more useful because more often, I use Ctrl to snap it to vertical or some simple angle like 60 deg.
The old behavior was not consistent with selector tool and node transforms. All other constrained rotations snap to 15 deg increments from the original position. It is possible to make a handle horizontal by retracting it and then dragging it out with Shift+Ctrl.
Too much consistency may be bad sometimes. Here, there's a very important difference: an arbitrary object does not have a "naturally vertical" position but a node handle *does*. And it is much more common to want to set it e.g. to 45 from vertical than to 45 from the current, usually approximate, position. So I would like this behavior to be restored, it was very convenient.
- Performance:
I fixed this recently (r9061). There were two issues: 1. libsigc++ is much slower than I expected, 2. I wasn't dropping motion events when there were many of them in the queue. Right now the performance should be comparable to 0.47, though probably further improvements are possible.
Yes, motion is now much snappier in 9066, thanks. This means I can now do some more performance testing with the 60000-node path and report the results :)
- When mouseovering a node, it says "click to select" even if it is already
selected. I'd like to copy this from the old tool as well, which suggested various modifiers for dragging instead.
I reused the GIMP paradigm of only showing the modifier tips when the relevant modifiers are pressed. This way the tip has some chance of being displayed in its entirety, especially on smaller screens. I can add a note like "(more: Shift, Ctrl, Alt)" at the end to make the modifier actions more discoverable.
This goes against Inkscape's common practice in other tools. We always try to show relevant modifiers, but we do it at the end, and sort them by importance, so the least important are most likely to be truncated. With your approach, you decide for the user what is unimportant, and thus deprive the users with wide screens of potentially useful information. So, while it might be reasonable to argue about tips on specific modifiers and their order, I don't think we should now start a purge on all of them, and I'd like them to be restored in Node tool. In any case, the misleading "click to select" should go.
- UI suggestion: since the show/hide seltrans handles button belongs
to visualization, it should be moved to the right end of the controls bar, next to node handles and node outline toggles.
There is a very important difference in behavior when transform handles are on: clicking on a selected node switches between rotation and scaling (consistent with selector) instead of making it the only one selected. This is the reason behind putting the button in front of the controls bar.
Well, this difference is indeed important (and I'm not sure it's justified, I need to test it some more and think) but in any case it is only visualization and behavior toggle, not some action on path. So moving them to the other visualization toggles makes perfect sense IMHO.
W dniu 8 lutego 2010 16:46 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>: OK, looks like I'll have to dig into it, as it still doesn't work in 9066.
Interesting, it worked after I switched to the node tool but after I selected any node it didn't. I fixed it harder in 9067.
Too much consistency may be bad sometimes. Here, there's a very important difference: an arbitrary object does not have a "naturally vertical" position but a node handle *does*. And it is much more common to want to set it e.g. to 45 from vertical than to 45 from the current, usually approximate, position. So I would like this behavior to be restored, it was very convenient.
OK
With your approach, you decide for the user what is unimportant, and thus deprive the users with wide screens of potentially useful information.
Same could be said about the previous "display everything at once" approach: by picking some ordering of the modifiers in the statusbar tip, we assign them different chances of being truncated and choose for the user which ones are important. I think that showing only the relevant tip when a modifier is pressed is the way to go, but it can be debated whether to show them all when no modifier is pressed. The hint at the end ("more: Shift, Ctrl, Alt, Shift+Ctrl") is enough IMO.
So, while it might be reasonable to argue about tips on specific modifiers and their order, I don't think we should now start a purge on all of them, and I'd like them to be restored in Node tool. In any case, the misleading "click to select" should go.
OK; I will change this to "click to select only this node", and when transform handles are on to "click to change transform handles mode"
Regards, Krzysztof
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 8 lutego 2010 16:46 użytkownik bulia byak <buliabyak@...400...> napisał:
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>: OK, looks like I'll have to dig into it, as it still doesn't work in 9066.
Interesting, it worked after I switched to the node tool but after I selected any node it didn't. I fixed it harder in 9067.
The "harder" fix does still not work for me :( It just zooms no matter whether i click or drag with middle button, with or without selected nodes.
With your approach, you decide for the user what is unimportant, and thus deprive the users with wide screens of potentially useful information.
Same could be said about the previous "display everything at once" approach: by picking some ordering of the modifiers in the statusbar tip, we assign them different chances of being truncated and choose for the user which ones are important.
Yes, we prioritize. But at least we give the chance to view everything. Even on a narrow screen you can hover the mouse over statusbar and read the entire tip.
I think that showing only the relevant tip when a modifier is pressed is the way to go, but it can be debated whether to show them all when no modifier is pressed.
Ideally, when one modifier is pressed, we should describe its function, *and* all other modifiers that can be pressed *with* it to change its function.
The hint at the end ("more: Shift, Ctrl, Alt, Shift+Ctrl") is enough IMO.
I think this is quite useless. Either display nothing (why?), or give a brief description of each.
OK; I will change this to "click to select only this node", and when transform handles are on to "click to change transform handles mode"
Yes, that makes sense, at least if we keep this difference in behavior (again, I'm not fully convinced yet).
2010/2/8 bulia byak <buliabyak@...400...>:
OK; I will change this to "click to select only this node", and when transform handles are on to "click to change transform handles mode"
Just use the consistent terminology: in Selector this is called "to toggle scale/rotation handles".
I just fixed middle button panning and rubberband-zoom by a change in node-tool.cpp. I don't quite understand how it could have worked for you before my change :)
W dniu 10 lutego 2010 22:33 użytkownik bulia byak <buliabyak@...400...> napisał:
I just fixed middle button panning and rubberband-zoom by a change in node-tool.cpp. I don't quite understand how it could have worked for you before my change :)
switch (event->type) { case GDK_MOTION_NOTIFY: { + if (event->button.button == 1) { + combine_motion_events(desktop->canvas, event->motion, 0);
Uh, that only works by accident, and it breaks the highlighting of paths. Why do you want to check for a field in the button structure, if what you've got is the motion structure? In other words you have a GdkEventMotion but access it as a GdkEventButton.
typedef struct { GdkEventType type; GdkWindow *window; gint8 send_event; guint32 time; gdouble x; gdouble y; gdouble *axes; guint state; guint button; GdkDevice *device; gdouble x_root, y_root; } GdkEventButton;
typedef struct { GdkEventType type; GdkWindow *window; gint8 send_event; guint32 time; gdouble x; gdouble y; gdouble *axes; guint state; gint16 is_hint; GdkDevice *device; gdouble x_root, y_root; } GdkEventMotion;
It looks like this check actually checks is_hint. is_hint is always false because as far as I know we do not use GDK_POINTER_MOTION_HINT_MASK. What you're looking for is probably changing "return true;" at the end of this case to "return false;", so that the motion event is always passed further up. I did this in 9081. Now that I see it I also have no idea how it worked for me before.
Regards, Krzysztof
2010/2/10 Krzysztof Kosiński <tweenk.pl@...400...>:
switch (event->type) { case GDK_MOTION_NOTIFY: {
- if (event->button.button == 1) {
combine_motion_events(desktop->canvas, event->motion, 0);
Uh, that only works by accident, and it breaks the highlighting of paths. Why do you want to check for a field in the button structure, if what you've got is the motion structure? In other words you have a GdkEventMotion but access it as a GdkEventButton.
Yep, sorry, I just copied that check from select-context without checking event type.
It looks like this check actually checks is_hint. is_hint is always false because as far as I know we do not use GDK_POINTER_MOTION_HINT_MASK. What you're looking for is probably changing "return true;" at the end of this case to "return false;", so that the motion event is always passed further up. I did this in 9081.
I didn't want to change behavior for button ==1. If it returns true, let it return true. Just don't gobble other buttons, that's all :)
Now that I see it I also have no idea how it worked for me before.
:)
2010/2/7 bulia byak <buliabyak@...400...>:
- Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing
selected should do the same in Node tool as in Selector, instead of doing nothing as now.
Addition: same applies to Tab and Shift+Tab: when nothing is selected they should select first/last object as they do in Selector.
Status as of revision 9070:
- Bug: Middle-button dragging and Shift-middle button zoom rubberband
still do not work.
Works for me
- Lost feature: when rotating/scaling nodes by keys and one node is
mouseovered, it is used as center of rotation and scaling.
Fixed
- Lost feature: when ctrl+alt+dragging a node, it should slide along
the handles _and their perpendiculars_.
Dubious usefulness, unless this only happens when handles are collinear. Pending on a few changes to the snapping API, otherwise it will bloat the drag handler to unmanageable length.
- Lost feature: when ctrl+alt+dragging a node, and it has a linear segment on
one side, it should slide along the continuation of that segment.
Fixed
- Lost feature: node sculpting. Will you work on it, or do you want
me to work on porting it?
Not started
- Bug: select a single node and rotate it by [] with or without Alt:
it rotates around some random center far away, instead of around itself.
Fixed
- Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The previous behaviour was: snap to origin, its opposite and perpendicular, to vertical/horizontal, and to 15 deg steps from vertical.
Fixed
- Lost feature: create a cusp node next to a linear segment; press Shift+S; it
becomes semismooth, aligned with the segment (correct); now press Shift+S again; old behavior is to make it fully smooth, extending the second handle, but your tool does nothing.
Fixed
- Lost feature: Rotating a handle with Shift before allowed to rotate
the second handle by the same angle, thus rotating a cusp node as a whole; now it does nothing.
Fixed
- Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing
selected should do the same in Node tool as in Selector, instead of doing nothing as now.
Fixed
- Performance:
Fixed
- Lost feature: the statusbar used to say how much total nodes are
there
Partially fixed (x of x nodes), working on subpath reporting
- Suggested feature: now that we can select multiple objects, the
statusbar hints must reflect that
I would rather show other hints than information about how many objects are selected, because this information is not very useful, and if the user really wants this information it's available by switching to the selector tool. The new paradigm of the node tool makes little distinction between subpaths in the same path and subpaths in different paths.
- Bug: when dragging a node handle, statusbar erroneously says "Move
by" instead of "Node handle:" as did the old tool.
Not a bug, there is no point in displaying "Node handle:" because this text is visible before the drag. The thing being dragged will not change during the drag so this information is redundant.
- When mouseovering a node, it says "click to select" even if it is already
selected.
Fixed. Also modified statusbar tips to include the "more:" bit - I think this is better than listing everything at once. The last hints have very little chance of being shown, and mouseovering the statusbar is impossible because those tips only appear when hovering over nodes.
- On the node deletion discussion, I found the current behavior
satisfactory: if you Del, you get curved approximation; if you Ctrl+del you get linear segment from linears. I think this is logical (unless I miss something).
Not started (waiting for some compromise to form)
- UI suggestion: since the show/hide seltrans handles button belongs
to visualization, it should be moved to the right end of the controls bar, next to node handles and node outline toggles.
I would really put it at the front, or at least after the path action buttons, because for me the association is more with modifying the path (think node transforms, rather that handle visibility)
- Crash: draw a path; ...
Should be fixed
- UI bug: create with Pen a Spiro path; ...
Not started
- Crash (somewhat hard to reproduce):
Didn't reproduce yet, but I put in some defensive checks that might have fixed it.
Regards, Krzysztof
On Tue, 2010-02-09 at 03:28 +0100, Krzysztof Kosiński wrote:
- Bug: select a single node and rotate it by [] with or without Alt:
it rotates around some random center far away, instead of around itself.
Fixed
Related lost feature, when rotating or scaling handles via kb w/ R/L-Alt modifiers, it no longer controls the individual handles.
Cheers, Josh
2010/2/8 Krzysztof Kosiński <tweenk.pl@...400...>:
Status as of revision 9070:
- Lost feature: when rotating/scaling nodes by keys and one node is
mouseovered, it is used as center of rotation and scaling.
Fixed
Works, thanks
- Lost feature: when ctrl+alt+dragging a node, it should slide along
the handles _and their perpendiculars_.
Dubious usefulness, unless this only happens when handles are collinear. Pending on a few changes to the snapping API, otherwise it will bloat the drag handler to unmanageable length.
Well, the old handler did all this, why can't yours? :)
And yes, it is most useful when handles are collinear, or there's only one handle, to move the node "perpendicular to itself". But it is useful, please restore it.
- Lost feature: when ctrl+alt+dragging a node, and it has a linear segment on
one side, it should slide along the continuation of that segment.
Fixed
Works, but I got a crash once while trying it, can't reproduce it anymore but just in case it said:
*** glibc detected *** i: munmap_chunk(): invalid pointer: 0x0d031c00 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0x12abff1] /lib/tls/i686/cmov/libc.so.6[0x12ad1f5] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x5e146f1] i[0x86cbb15]
Also a related bug:
6.1. When you ctrl+alt+drag a node next to linear segment, and you release mouse while cursor is not over the node itself, next attempt to select by rubberband fails. You need to do it one more time to work.
- Lost feature: When rotating a handle with Ctrl, it now snaps to the original
position and 15 deg increments from that original position. The previous behaviour was: snap to origin, its opposite and perpendicular, to vertical/horizontal, and to 15 deg steps from vertical.
Fixed
You missed the "and perpendicular" part :)
Also, just in case, the "15 degrees" everywhere should be "the value set in prefs", 15 is just the default (you probably got this right, just clarifying)
- Lost feature: create a cusp node next to a linear segment; press Shift+S; it
becomes semismooth, aligned with the segment (correct); now press Shift+S again; old behavior is to make it fully smooth, extending the second handle, but your tool does nothing.
Fixed
Works but buggy: the second handle appears in some random position instead of aligned with the segment!
- Suggested feature: now that we can edit multiple paths, Ctrl+A when nothing
selected should do the same in Node tool as in Selector, instead of doing nothing as now.
Fixed
Please also enable Tab/Shift+tab
- Suggested feature: now that we can select multiple objects, the
statusbar hints must reflect that
I would rather show other hints than information about how many objects are selected, because this information is not very useful, and if the user really wants this information it's available by switching to the selector tool. The new paradigm of the node tool makes little distinction between subpaths in the same path and subpaths in different paths.
Exactly, and here you gave the reason why we should in fact show this information :) See, it's no distinction for your code (kudos to you), but it's different concepts and behavior for the user. So, being able to easily find out how many of these things are actually different objects and how many are subpaths is very useful. And if you're not using subpaths, you're not losing anything, there won't be any space wasted on the number of subpaths then. Ditto for paths when only one path is selected.
- Bug: when dragging a node handle, statusbar erroneously says "Move
by" instead of "Node handle:" as did the old tool.
Not a bug, there is no point in displaying "Node handle:" because this text is visible before the drag. The thing being dragged will not change during the drag so this information is redundant.
Then please make it "Move handle by" instead of "Move by" which is a bit confusing.
- When mouseovering a node, it says "click to select" even if it is already
selected.
Fixed. Also modified statusbar tips to include the "more:" bit - I think this is better than listing everything at once. The last hints have very little chance of being shown, and mouseovering the statusbar is impossible because those tips only appear when hovering over nodes.
"click clear" => "click to clear"
also when selecting nodes I get:
(i:10657): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 125: Element 'markup' was closed, but the currently open element is 'b'
- UI suggestion: since the show/hide seltrans handles button belongs
to visualization, it should be moved to the right end of the controls bar, next to node handles and node outline toggles.
I would really put it at the front, or at least after the path action buttons, because for me the association is more with modifying the path (think node transforms, rather that handle visibility)
OK, as a compromise I would agree to placing it after the X/Y fields and unit selector, right before the three visibility toggles.
- Crash: draw a path; ...
Should be fixed
Not quite. Now you just need to do more undoing before it crashes :)
- go to Pencil in normal mode
- draw any three paths
- select paths 1 and 2, object>clip>set
- select result and path 3, object>mask>set
- go to Node, toggle clip and mask view if not yet on
- drag blue path's node
- drag green paths' node
- drag original (red) path's node
- undo 8 times => crash
18.1. A related bug: if you draw path in Spiro mode and then clip and/or mask it, in Node tool its clip/mask will not be editable even if you turn on their toggles.
- Crash (somewhat hard to reproduce):
Didn't reproduce yet, but I put in some defensive checks that might have fixed it.
So far I couldn't reproduce the crash, but here's a related bug:
20.1. Perform steps of 20, but then, after the last undo which used to crash, perform Redo (Shift+Ctrl+Z) . Notice that the actual path (black) and the source path (green) are out of sync.
2010/2/9 bulia byak <buliabyak@...400...>:
Not quite. Now you just need to do more undoing before it crashes :)
- undo 8 times => crash
this is fixed in the latest rev, thanks!
On 8/2/10 04:48, bulia byak wrote: ... a list of 20 items about the new node tool. I'll add
21) lost feature: snapping of handles to grids & guides when dragging
Would it be difficult to add this back? It might more useful for technical drawings than for artistic use of Inkscape I guess, nevertheless a very appreciated feature in Inkscape 0.47 to be able to fine-tune curves (e.g. to create symmetric or equally curved parts within a path) because we can't edit the coordinates of the handles numerically or relative to other nodes/handles.
~suv
On 2/8/10, bulia byak wrote:
Krzysztof,
I finally found time to test the new node tool. Overall it feels great, but of course I found many small and not so small things to fix :) #1 is my personal pet peeve, if you can't see it please just give me pointers to the code which passes events up and I'll have a look myself.
Just a quick note. Translatable messages from src/ui/tool/node-tool.cpp don't seem to be willing to appear in the final POT file.
And "<b>%u of %u nodes</b>" really makes plural forms broken.
Alexandre
Krzysztof,
revisiting my old comments and testing the latest build, I found a couple remaining issues that need to be fixed before the release:
1. When ctrl+alt+dragging a node, it should slide along the handles *and their perpendiculars*; similarly when rotating a handle with Ctrl, it should snap to origin, its opposite *and perpendicular*, to vertical/horizontal, and to 15 deg steps from vertical - all works except the perpendiculars.
2. Node sculpting now works - thanks! - but has two problems:
2a. It's not pressure sensitive - no way to make pinchy or blunt profile as before by pressing pen harder or softer
2b. Node handles are not sculpted based on their position! so if you drag the middle of a text string down it becomes all jagged because all handles stay horizontal while the text itself is bent.
Thanks!
W dniu 28 marca 2010 22:01 użytkownik bulia byak <buliabyak@...400...> napisał:
Krzysztof,
revisiting my old comments and testing the latest build, I found a couple remaining issues that need to be fixed before the release:
- When ctrl+alt+dragging a node, it should slide along the handles
*and their perpendiculars*; similarly when rotating a handle with Ctrl, it should snap to origin, its opposite *and perpendicular*, to vertical/horizontal, and to 15 deg steps from vertical - all works except the perpendiculars.
Will fix soon (over the coming week).
- Node sculpting now works - thanks! - but has two problems:
2a. It's not pressure sensitive - no way to make pinchy or blunt profile as before by pressing pen harder or softer
In case you haven't noticed, I made an effort to make all drags "history-free": the effect of a drag is not dependent on the history of mouse movements or modifiers pressed, only on the difference between initial and current cursor position and currently pressed modifiers. If you release a modifier while dragging a node, it will behave as if you started the drag without the modifier pressed. For example dragging some node and then pressing Alt will cause the nodes to be sculpted from their initial positions. I hope you understand what I I mean :)
This way things are consistent with other tools, and more user friendly: people are in general better at specifying position deltas that at specifying an entire movement history. However, it also precludes any sensible use of pressure sensitivity, because pressure sensitive drags cannot be history-free: you want the history of pressure to affect what the final effect will look like. So we can either make pressure-sensitive Alt-dragging the only action that breaks this paradigm, or drop this feature.
2b. Node handles are not sculpted based on their position! so if you drag the middle of a text string down it becomes all jagged because all handles stay horizontal while the text itself is bent.
Oops, I did the testing on a rectangle with some inserted nodes so I didn't catch this. Will fix as well.
Regards, Krzysztof
On Mar 28, 2010, at 2:40 PM, Krzysztof Kosiński wrote:
This way things are consistent with other tools, and more user friendly: people are in general better at specifying position deltas that at specifying an entire movement history. However, it also precludes any sensible use of pressure sensitivity, because pressure sensitive drags cannot be history-free: you want the history of pressure to affect what the final effect will look like. So we can either make pressure-sensitive Alt-dragging the only action that breaks this paradigm, or drop this feature.
No, that's not the only way to do it. Probably those two "all-or-nothing" were the *simplest* ways to do it. But I'm sure much more can be done.
Of course the trick here is to look carefully at the overall codebase and such, so as to not accidentially break something else in adding a new tuned behavior.
2010/3/28 Krzysztof Kosiński <tweenk.pl@...400...>:
In case you haven't noticed, I made an effort to make all drags "history-free": the effect of a drag is not dependent on the history of mouse movements or modifiers pressed, only on the difference between initial and current cursor position and currently pressed modifiers. If you release a modifier while dragging a node, it will behave as if you started the drag without the modifier pressed. For example dragging some node and then pressing Alt will cause the nodes to be sculpted from their initial positions. I hope you understand what I I mean :)
This way things are consistent with other tools, and more user friendly: people are in general better at specifying position deltas that at specifying an entire movement history. However, it also precludes any sensible use of pressure sensitivity, because pressure sensitive drags cannot be history-free: you want the history of pressure to affect what the final effect will look like.
How so? The current displacement of each selected node depends on: 1) its distance from dragged node; 2) the vector of the dragged node movement; and 3) value of pressure _at this time_ which affects the bell shape of the profile. Where is history in this?
W dniu 29 marca 2010 00:42 użytkownik bulia byak <buliabyak@...400...> napisał:
How so? The current displacement of each selected node depends on: 1) its distance from dragged node; 2) the vector of the dragged node movement; and 3) value of pressure _at this time_ which affects the bell shape of the profile. Where is history in this?
When you release the pen, the pressure gradually changes from high to zero. You get a sharp bell profile that corresponds to the very low pressure reported in the last motion event before the release event.
You can get a "fat" profile only if you you are a ninja and can release the pen fast enough that the gradual decrease in pressure won't be picked up by the tablet :)
Regards, Krzysztof
2010/3/28 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 29 marca 2010 00:42 użytkownik bulia byak <buliabyak@...400...> napisał:
How so? The current displacement of each selected node depends on: 1) its distance from dragged node; 2) the vector of the dragged node movement; and 3) value of pressure _at this time_ which affects the bell shape of the profile. Where is history in this?
When you release the pen, the pressure gradually changes from high to zero. You get a sharp bell profile that corresponds to the very low pressure reported in the last motion event before the release event.
You can get a "fat" profile only if you you are a ninja and can release the pen fast enough that the gradual decrease in pressure won't be picked up by the tablet :)
Ah, yes, we had this problem before. The solution was to let go of Alt first, and then release the pen. Still, it was somewhat clumsy, and I now understand why you can't do that with your no-history implementation.
But we can do something better this time. For example limit the rate of pressure lookups - make the function returning pressure look at the real pressure every 10th call, otherwise return a cached value. Yeah, I know, this is almost like adding a history, but not quite, and seems a quite harmless little hack :)
Krzysztof,
just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope.
W dniu 19 kwietnia 2010 17:06 użytkownik bulia byak <buliabyak@...400...> napisał:
just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope.
Thanks for noticing, I didn't know about this feature. IIRC there are 4 things left to fix: 1. Ctrl+Alt node drag (snapping to perpendiculars). This requires some fixes to snapping in general, to remove the pointless "node to constraint" snap indicator in the selector tool as well 2. Crashes when undoing an action that creates an LPE while one of its parameters is edited. 3. Other odd crashes when undoing. 4. Flowtext rectangle editing. 5. Pressure sensitivity when sculpting (if I figure out a sensible behavior for it)
2010/4/19 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked,
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ).
Regards, Krzysztof
On 20/4/10 00:53, Krzysztof Kosiński wrote:
W dniu 19 kwietnia 2010 17:06 użytkownik bulia byak <buliabyak@...400...> napisał:
just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope.
Thanks for noticing, I didn't know about this feature. IIRC there are 4 things left to fix:
- Ctrl+Alt node drag (snapping to perpendiculars). This requires some
fixes to snapping in general, to remove the pointless "node to constraint" snap indicator in the selector tool as well 2. Crashes when undoing an action that creates an LPE while one of its parameters is edited. 3. Other odd crashes when undoing. 4. Flowtext rectangle editing. 5. Pressure sensitivity when sculpting (if I figure out a sensible behavior for it)
6. [bug #555449] missing feature: 'duplicate nodes' (including shortcut) 7. [bug #532905] missing shortcurt: 'Shift+L' for changing curve to line 8. editing a clippath or mask often fails if clippath or mask is a shape (vs. a path) and clips or masks a single object (vs. a group) (not filed as bug yet because I haven't figured out how to consistently reproduce it.)
~suv
2010/4/19 ~suv <suv-sf@...58...>:
On 20/4/10 00:53, Krzysztof Kosiński wrote:
W dniu 19 kwietnia 2010 17:06 użytkownik bulia byak <buliabyak@...400...> napisał:
just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope.
Thanks for noticing, I didn't know about this feature. IIRC there are 4 things left to fix:
- Ctrl+Alt node drag (snapping to perpendiculars). This requires some
fixes to snapping in general, to remove the pointless "node to constraint" snap indicator in the selector tool as well 2. Crashes when undoing an action that creates an LPE while one of its parameters is edited. 3. Other odd crashes when undoing. 4. Flowtext rectangle editing. 5. Pressure sensitivity when sculpting (if I figure out a sensible behavior for it)
- [bug #555449] missing feature: 'duplicate nodes' (including shortcut)
- [bug #532905] missing shortcurt: 'Shift+L' for changing curve to line
- editing a clippath or mask often fails if clippath or mask is a shape
(vs. a path) and clips or masks a single object (vs. a group) (not filed as bug yet because I haven't figured out how to consistently reproduce it.)
and 9. a thing I already reported, still not fixed: sculpting node handles
On 4/20/10, Krzysztof Kosiński wrote:
Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked,
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ).
What does *multi*shape editing has to do with it? All the tool has to do is edit shapes like it has been doing for years.
Alexandre
2010/4/20 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On 4/20/10, Krzysztof Kosiński wrote:
Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked,
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ).
What does *multi*shape editing has to do with it? All the tool has to do is edit shapes like it has been doing for years.
The difference is that now the clipping mask and the base shape are edited at the same time - the clip / mask editing buttons are toggles and do not change the selection. Before that, clip / mask editing buttons were pushbuttons that selected the clip or mask for editing.
It should still be possible to edit 1 normal shape in addition to all the paths, so I think this is actually a bug somewhere in my code.
Regards, Krzysztof
On 23/4/10 00:02, Krzysztof Kosiński wrote:
2010/4/20 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On 4/20/10, Krzysztof Kosiński wrote:
Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked,
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ).
What does *multi*shape editing has to do with it? All the tool has to do is edit shapes like it has been doing for years.
The difference is that now the clipping mask and the base shape are edited at the same time - the clip / mask editing buttons are toggles and do not change the selection. Before that, clip / mask editing buttons were pushbuttons that selected the clip or mask for editing.
It should still be possible to edit 1 normal shape in addition to all the paths, so I think this is actually a bug somewhere in my code.
See attached file with various simple clips ('shape clips shape' and 'shape clips path'): whether the clippaths can be edited with the node-tool varies from session to session, however those within the red circles fail most of the times. Opening the file as a second document from within Inkscape can result in opposed behavior (the ones that had been editable now fail and those that failed now show the handles).
The bug seems to be related to information held in memory, not to the actual data in the file: select, unclip and clip again some of the colored clipped shapes and suddenly the clippaths may no longer show their handles. Restart Inkscape and the same clips that previously failed now can be edited (i.e. handles are visible and draggable).
Also note that sometimes (?) clippaths (shapes) still have the editable nodes in the original location the shape had been created at and not at the location where the actual clipping is rendered.
~suv
recently noticed difference (0.47 <-> 0.47+devel r9290):
- Earlier versions of the node tool (tested with 0.46 and 0.47) supported the keyboard shortcut 'Shift+D' to duplicate selected nodes [1] - this no longer works in the new node tool. Was it a deliberate decision to not support this operation or is there an alternative shortcut I'm not aware of? Could it be added back?
~suv
[1] http://article.gmane.org/gmane.comp.graphics.inkscape.devel/99 http://inkscape.org/doc/keys047.html#id2249730
(whups, forgot to reply to the list)
I just tested that, and it looks like a pretty neat trick. I never knew about it, but you never know what tutorial out there might still use it.
The new stuff doesn't seem to support it, as you pointed out. I think that's some pretty important functionality, and if it was me, I'd add that back in.
I filed a bug report on this. I'm new to this project, so if this is stepping on any toes, let me know. It can be found here: https://bugs.launchpad.net/inkscape/+bug/555449
- Alex
On Sun, Apr 4, 2010 at 10:31 AM, ~suv <suv-sf@...58...> wrote:
recently noticed difference (0.47 <-> 0.47+devel r9290):
- Earlier versions of the node tool (tested with 0.46 and 0.47)
supported the keyboard shortcut 'Shift+D' to duplicate selected nodes [1] - this no longer works in the new node tool. Was it a deliberate decision to not support this operation or is there an alternative shortcut I'm not aware of? Could it be added back?
~suv
[1] http://article.gmane.org/gmane.comp.graphics.inkscape.devel/99 http://inkscape.org/doc/keys047.html#id2249730
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (13)
-
unknown＠example.com -
Alex Trujillo -
Alexandre Prokoudine -
bulia byak -
Diederik van Lierop -
Jasper van de Gronde -
Jed Frechette -
John Cliff -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
LucaDC -
~suv