2010/2/8 Krzysztof Kosiński <tweenk.pl@...>:
> Status as of revision 9070:
>> 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_.
> 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.
>> 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.
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: =========
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
>> 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.
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,
>> 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.
Works but buggy: the second handle appears in some random position
instead of aligned with the segment!
>> 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.
Please also enable Tab/Shift+tab
>> 13. 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.
>> 14. 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
>> 15. When mouseovering a node, it says "click to select" even if it is already
> 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'
>> 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.
> 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.
>> 18. 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.
>> 20. 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.
Inkscape. Draw Freely.