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.