On Mon, 23 Oct 2017 22:04:04 +0200 Jabier Arraiza <jabier.arraiza@...2893...> wrote: Hola Jabier, I'd appreciate it if you could start fixing these details, I won't be able to look into this myself before the week-end. Maybe item 3. needs some more discussion. Item 4. is just an observation, it's not urgent at all. Thanks, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

On Tue, 24 Oct 2017 00:01:11 +0200 Jabier Arraiza <jabier.arraiza@...2893...> wrote: Ping. Hi Jabier, any news about this issue? Last time I checked a few days ago the behavior of object control points still shows the problems presented in the first message of this thread. If you are busy I'll try to take a look myself during the week-end. Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

On Sat, 21 Oct 2017 19:59:14 +0200 Antonio Ospite <ao2@...3619...> wrote: OK, after about one year, I managed to find some motivation to start looking at these issues myself. :) 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. 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). 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? 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 -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?