Thanks for the patch! There are some formatting and whitespace issues here; could you fix those up first?

In testing it out, I really like it! I might even make the handles a bit larger for more touch-friendliness. Not a lot larger, just a bit.

Can you add some before & after screenshots (or vids) for VDG ?

There is actually one "problem" I noticed. If you resize the rectangle from big to small (where the handles become free-floating), the cursor is at the end still there, where the handler should be in the normal mode. So the handler moved away from the cursor and you have to move the cursor back to the drag handler, if you want to resize the rectangle again. I'm actually not quite sure if that's a problem, but it's definitely different to how it behaved before the patch. One possible solution would be to move the cursor automatically to the drag handler it grabbed before. But it might look strange if the cursor suddenly jumps somewhere else?
Some opinions on this would be great!
@ngraham Is there a possibility to detect a touch device? If not what radius would you prefer? I also included an option to make the area, where resizing events are noticed bigger than the actual handles. At the moment the area is twice as big see "increaseDragAreaFactor". What value would you prefer for that?

In D23322#516108, @Leon0402 wrote:

There is actually one "problem" I noticed. If you resize the rectangle from big to small (where the handles become free-floating), the cursor is at the end still there, where the handler should be in the normal mode. So the handler moved away from the cursor and you have to move the cursor back to the drag handler, if you want to resize the rectangle again. I'm actually not quite sure if that's a problem, but it's definitely different to how it behaved before the patch. One possible solution would be to move the cursor automatically to the drag handler it grabbed before. But it might look strange if the cursor suddenly jumps somewhere else?
Some opinions on this would be great!

Moving the cursor is an option (but might it not work on Wayland?), though I'm not sure this is actually a serious problem in the first place.

@ngraham Is there a possibility to detect a touch device? If not what radius would you prefer? I also included an option to make the area, where resizing events are noticed bigger than the actual handles. At the moment the area is twice as big see "increaseDragAreaFactor". What value would you prefer for that?

Since 2-in-1 laptops can be interacted with using both touch and a traditional mouse or touchpad, I would instead check to see if each individual click was a touch event instead. For this, can use https://doc.qt.io/qt-5/qmouseevent.html#source

Once a touch event is detected, maybe enlarge the handles until the next click event.

@ngraham You have a 2-1 device, right? Could you please test if the the handles` radius increases as soon as you use touch and goes back to normal as soon as you use your mouse again? (change should happen on single click/touch)

Also, I would appreciate some feedback from anyone regarding the size of the handles in mouseMode, in touchMode and the factor to make the mouse area of the handles bigger (currently set to 2.0).

Much better. Would it be possible to only move the markers on the edge which is at the border or would that look weird?

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

This is how it would look like

Personal opinion:

• Not really better, but also not worse than the prior design
• Would require major code changes. Currently there is only one offset for each handle (we would need an offset property for every handle then), currently spectacle just looks if there is at least one screen edge in it's way ... for the change we would need to find out, we would need to check very screen edge separately and handle "corner situations" (where it's too close to two edges) as the offset for the corner handle should then only be applied once and not twice -> Possibly even more (design?) issues when the rectangle is small and the handles become free-floating

It's probably not worth it and brings more disadvantages than advantages.

In D23322#516673, @davidre wrote:

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

In theory this should be automatically resolved as the handles become free-floating if the size is too small. So they already have an offset of say 40px, which would be decreased by radius/2 ... so it's still about 35px outside of the rectangle and moving the rectangle should be possible without problems (Disabling the feature then might be still a good idea, as the space between the handles should be consistent). Or did I misunderstood you?
This means also that you cannot resize the rectangle on the edges atttached to the screen edges, if the rectangle is very small. But I cannot imagine anyone having a small rectangle in the screen corner/ at the screen edge and then wanting to make the rectangle even smaller from that side.

In D23322#516683, @Leon0402 wrote:

This is how it would look like

Personal opinion:

• Not really better, but also not worse than the prior design
• Would require major code changes. Currently there is only one offset for each handle (we would need an offset property for every handle then), currently spectacle just looks if there is at least one screen edge in it's way ... for the change we would need to find out, we would need to check very screen edge separately and handle "corner situations" (where it's too close to two edges) as the offset for the corner handle should then only be applied once and not twice -> Possibly even more (design?) issues when the rectangle is small and the handles become free-floating
  
  It's probably not worth it and brings more disadvantages than advantages.

In D23322#516673, @davidre wrote:

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

In theory this should be automatically resolved as the handles become free-floating if the size is too small. So they already have an offset of say 40px, which would be decreased by radius/2 ... so it's still about 35px outside of the rectangle and moving the rectangle should be possible without problems (Disabling the feature then might be still a good idea, as the space between the handles should be consistent). Or did I misunderstood you?
This means also that you cannot resize the rectangle on the edges atttached to the screen edges, if the rectangle is very small. But I cannot imagine anyone having a small rectangle in the screen corner/ at the screen edge and then wanting to make the rectangle even smaller from that side.

Whoops the sentence is missing the important part. I was referring to the ability to resize the rectangle anywhere on it's edges not only on the dots.

In D23322#516683, @Leon0402 wrote:

This is how it would look like

or like this

Personal opinion:

• Not really better, but also not worse than the prior design
• Would require major code changes. Currently there is only one offset for each handle (we would need an offset property for every handle then), currently spectacle just looks if there is at least one screen edge in it's way ... for the change we would need to find out, we would need to check very screen edge separately and handle "corner situations" (where it's too close to two edges) as the offset for the corner handle should then only be applied once and not twice -> Possibly even more (design?) issues when the rectangle is small and the handles become free-floating
  
  It's probably not worth it and brings more disadvantages than advantages.

In D23322#516673, @davidre wrote:

This also removes the ability to resize the rectangle so that it can be moved when it's really small. I think we should keep that feature and only disable it at problematic sizes.

In theory this should be automatically resolved as the handles become free-floating if the size is too small. So they already have an offset of say 40px, which would be decreased by radius/2 ... so it's still about 35px outside of the rectangle and moving the rectangle should be possible without problems (Disabling the feature then might be still a good idea, as the space between the handles should be consistent). Or did I misunderstood you?
This means also that you cannot resize the rectangle on the edges atttached to the screen edges, if the rectangle is very small. But I cannot imagine anyone having a small rectangle in the screen corner/ at the screen edge and then wanting to make the rectangle even smaller from that side.

Another idea would be to only move them away from the edge but not change the height:

Okay going to implement the feature that only some of the handles move inside (and we can see then if it's worth it) and going to implement the feature that resizing work on the rectangle`s edges works as well if the rectangle is not too small.