Great! At first glance it works very well.
However I noticed some details that could be improved:

1. When holding 'J', the radius should respond to horizontal and vertical gestures. Also, the action of enlarging/shrinking the radius should not be reversed when moving in one direction (apparently, it should be related to an absolute distance from a reference point).
2. I see that in successive repetitions of the rectangle + J + radius change command, the internal reference value accumulates with the mouse movement, regardless of whether the radius has changed (there is no radius change when we reach the maximum and minimum limits). This makes it seem like the radius modification stops working if too much "internal movement" has accumulated. This mouse movement accumulator should be reset for each new rectangle drawn.

Comments:

1. I think it's great that the radius is maintained for future rectangles.
2. Perhaps there should be an entry in the context bar to define the radius. However, as a first implementation, it seems fine to me.

@Gasparoken thanks for the feedback!

When holding 'J', the radius should respond to horizontal and vertical gestures.

Sure, no problem.

Also, the action of enlarging/shrinking the radius should not be reversed when moving in one direction (apparently, it should be related to an absolute distance from a reference point).

👍

I see that in successive repetitions of the rectangle + J + radius change command, the internal reference value accumulates with the mouse movement, regardless of whether the radius has changed (there is no radius change when we reach the maximum and minimum limits). This makes it seem like the radius modification stops working if too much "internal movement" has accumulated. This mouse movement accumulator should be reset for each new rectangle drawn.

I'm not sure if I'm getting this right. The radius doesn't have a hard limit, basically it is visually limited by the size of the rectangle, but the radius can be bigger than the visible radius. If you set a big corner radius it will be adjusted according to rectangle size. So, are you proposing that the radius should not be increased once the max visible radius for the current rectangle size is reached? In which case, once the user reached the max visible radius they would be forced to resize the rectangle first and then increment the radius, right?

The radius doesn't have a hard limit, basically it is visually limited by the size of the rectangle, but the radius can be bigger than the visible radius.

IMO, this is not convenient because you lose the visual feedback of the radius.

So, are you proposing that the radius should not be increased once the max visible radius for the current rectangle size is reached?

Yes, that's right.

In which case, once the user reached the max visible radius they would be forced to resize the rectangle first and then increment the radius, right?

No, IMO the correct behavior is:

1. You can modify the rectangle size when the 'J' key isn't pressed, then
2. When 'J' is pressed the radius size should be modified only

I think it's best for the artist to modify one parameter at a time, rather than enabling a double modification (radius + rectangle size ).

I can imagine your approach, but I found one case that might be annoying for the artist:
When the radius size is near to the maximum, it's hard to know if the radious is actually the max. We'll notice of it when the size of the rectangle increases, then the original rectangle size is loss., then you can decrease the size of the rectangle until the original rectangle size.
It doesn't sound bad, but I prefer the two-step approach.

Anyway, maybe I misinterpreted your proposal, or you've come up with something better. Let me know if that's the case.

Something has changed...now the slider doesn't show up anymore...I will be fixing that along the other things.

EDIT: Alright, maybe nothing changed...it turns out that in single window UI mode it works, but with multiple windows it doesn't...not sure if it worked before the rebase.

@dacap Last commit adds the item 4 you mentioned in your last review, but it doesn't work on macOS (using multiple windows). However, it does work on Windows (I didn't test it on Linux yet).

The issue on macOS occurs because when the user starts dragging something the mouseMove events received are coming from the window that received the mouseDown. Then the position of the mouse is relative to that native window, and not to the popup window that has the widget to which I'm trying to offer the capture, hence the windows manager is not able to pick the slider. It seems that this is due to the fact that in macOS there is no captureMouse() and releaseMouse() implementations. So I'll see if I can do something about this to fix it.

I couldn't find any fix today. I think it would be better to leave it as is and file a new issue for macOS later. Thus we don't delay the rounded rectangle support anymore.

I've tried:

• Using a global variable to store the view that captured the mouse and then use it to adjust the mouse position returned in the mouse events...this almost worked.
• Using events to simulate a mouse up and a mouse down when the mouse capture changes. I've tried with NSEvents and CGEvents...couldn't make them work.

I've tested on Linux and it works great! I'll merge it as it is, we can take a look to the macOS issue later. I'm not sure if the UI will be kept in this way, or a text field that is expanded in the same context bar might be a better option in the future (so the corner radius button acts like a checkbox to make show/hide the text field in the same context bar).