Added new drag Handlers for the rectangular region option, which become free-floating) if there is not enough space (results in a bigger touch area for moving the rectangle) and are more touch-friendly.
BUG: 371843
FIXED-IN: 19.12.0
ngraham | |
davidre |
Spectacle | |
VDG |
Added new drag Handlers for the rectangular region option, which become free-floating) if there is not enough space (results in a bigger touch area for moving the rectangle) and are more touch-friendly.
BUG: 371843
FIXED-IN: 19.12.0
Before:
No Linters Available |
No Unit Test Coverage |
Buildable 15419 | |
Build 15437: arc lint + arc unit |
Thanks for the patch! There are some formatting and whitespace issues here; could you fix those up first?
src/QuickEditor/QuickEditor.cpp | ||
---|---|---|
52 | Unrelated change | |
258 | unnecessary whitespace change | |
442 | unrelated change (should be fixed, but not in this patch) | |
805 | unrelated change | |
src/QuickEditor/QuickEditor.h | ||
72 | unnecessary whitespace change |
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.
src/QuickEditor/QuickEditor.cpp | ||
---|---|---|
29–32 | best to never use decimal values when describing the size of UI elements, since it can and often does lead to blurriness and scaling anomalies at various scale factors. |
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?
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).
It works perfectly. Nicely done. The circle sizes seem just right, too.
@davidre, what do you think?
Removed unused property: Instead of a fixed size for the mouse area, it's a multiple of the handle`s size instead as it varies (touch or mouse mode)
Temporary fix for multiple screen issue: Other parts (like the tooltip) don't handle multiple screens either. Will fix all these issue in a seperate patch
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:
It's probably not worth it and brings more disadvantages than advantages.
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.
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.
Implemented new behaviour of handlers when they touch a screen edge
Rectangle can no be resized on edges, if the rectangle is big enough (>= 100x100)