On Sat, 21 Oct 2017 19:59:14 +0200 Antonio Ospite <ao2@...3619...> wrote:
Hi,
I was looking into fixing https://bugs.launchpad.net/inkscape/+bug/1707919 and, after compiling a recent Inkscape version I noticed that the behavior of knot changed wrt. selection and dragging compared to 0.92.x.
After some research on the mailing list I found the change mentioned here: https://inkscape.org/en/news/2017/07/12/what-happened-hackfest-2017/
I can see the benefit of keeping knots selected to be able to move them with the keyboard but I still find the new behavior a little unintuitive, at lest for shape editing:
OK, after about one year, I managed to find some motivation to start looking at these issues myself. :)
- The colors of the mouse-over and selected states are the same, maybe the coloring scheme of node paths can be copied: where selected color is different from the mouse-over and dragging colors which are the same.
The current default colors for knots states are:
NORMAL -> white MOUSEOVER -> red DRAGGING -> blue SELECTED -> red
Now that knots are actually selectable after commit ff04a08000 (working on knots selection, 2017-07-01), using the *same* color for the MOUSEOVER and SELECTED looks like a contradiction to me considering that one is an instantaneous indicator and the other represents a more persistent state.
MOUSEOVER and DRAGGING are more similar, so switch to the following style:
NORMAL -> white MOUSEOVER -> red DRAGGING -> red SELECTED -> blue
The new style also matches what path nodes look like.
- Previously selected knots look still selected when _another_ knot is dragged without pressing Shift. Steps to replicate:
- Change size of a rect using one corner.
- Then change the size using the opposite corner. The firs corner looks still selected.
I'll solve this by updating the knots selection status in a newly added "mousedown" signal handler, instead of doing it when the mouse button is released (click/ungrabbed signals).
Shift-click does not really select arc knots for ellipses, or rounding knots for rects, because this action is already used for something else, e.g. to close the arc instead.
Would it be possible to use Ctrl-Shift-click for the current function and leave Shift-click for the normal select behavior? IMHO this would be more consistent.
I am not going to tackle this just yet, maybe we can discuss the behavior in another thread; the problem is that Shift-click can both select knots and perform some other operations (e.g. reset rounded corner radius for rects) at the same time. Do we want this ambiguity?
Should I open a bug report for that?
- Dragging with the mouse only affects the last selected knot, even if multiple ones are selected, but this is not a big deal, the behavior is different compared to path nodes, but both make sense IMHO.
Not sure what to do about this one, should we move *all* the selected knots with the mouse, just like it's done for path nodes? The behavior might be weird when selecting knots with different functions, but this can already be done by moving multiple knots with the keyboard anyway, so whatever decision is made let's be consistent between mouse and keyboard movement.
Should I open a bug report for that too?
Another things I noticed about knots:
5. Moving knots up and down with the keyboard moves them in the opposite direction when the Y axis goes downwards.
This happens because commit 1fa0c72b66 (New option to invert y-axis, 2018-09-12) forgot to handle Y direction in src/ui/tools/tool-base.cpp.
I'll fix the issue by applying the Y axis direction factor just like it's done in src/ui/tool/control-point-selection.cpp, but I haven't checked all the other tools.
I am going to send a merge request with the fixes I got so far, and if there is interest we can discuss about the remaining issues (3. and 4. from above).
Thanks, Antonio