selector does not work properly for small width/height selections

[PhilDevProg]

trafficstars

Describe the bug When resizing a line, it isn't placed at the same point after resizing.

To Reproduce Steps to reproduce the behavior:

1. Create a line
2. Select it
3. Resize it
4. See error

Expected behavior The line should stay at its place.

** Console Output **

 2023-04-14T17:55:24.239Z DEBUG rnote::app::imp > ... env_logger initialized

(rnote:2): Gtk-CRITICAL **: 19:55:55.955: The layout manager of type GtkBoxLayout 0x55fb17c30870 does not create GtkLayoutChild instances

Screenshots Bildschirmaufzeichnung vom 2023-04-14, 19-55-35.webm

Desktop (please complete the following information):

• OS: Fedora
• Version: 37
• Installation source: Flatpak
• Desktop Environment: GNOME 43.4

[ElbertCode]

This also happens with the single line shape and seems to be because the selection box of the stroke is smaller than the minimum size of the resizer. This is why, at least for me, the problem no longer occurs when the stroke is thick enough. Since the position of the shape is always placed in the middle of the selection, it is shifted slightly to the right. This should be fixable if the selection would be enlarged the same amount in all directions when resizing.

[PhilDevProg]

This also happens with single strokes and seems to be because the selection box of the stroke is smaller than the minimum size of the resizer. This is why, at least for me, the problem no longer occurs when the stroke size is large enough. Since the position of the shape is always placed in the middle of the selection, it is shifted slightly to the right. This should be fixable if the selection would be enlarged the same amount in all directions when resizing.

Yes, you're right! I didn't notice that.

[Kneemund]

This bug applies to any kind of stroke/object that's smaller than the minimum size, and is caused by the following lines:

https://github.com/flxzt/rnote/blob/53ca51f19ee1aba54093b244f46549b17dd76490/rnote-engine/src/pens/selector/penevents.rs#L268-L272

A potential fix is appending .mins(&start_bounds.extents()) to the parameter.

I'm not sure why this specific minimum width/height is enforced here anyway - wouldn't it be enough to limit the scale factors to > 0? IMO, ensuring that the buttons stay clickable should be done while rendering the selection, not when the user scales it.

EDIT: NVM, that doesn't fully fix this.

[Doublonmousse]

A common solution to this is to draw the selection rectangle larger than the object.

An example with xournal The padding is done in a way that baselines don't shift around. But when enlarging things, the padding gets proportionally bigger so a bit of precision is lost.

Having this padding only happen on smaller (or thinner) object could be done but this also comes with some more global state to keep for the resize (at the moment resizing is done in small increments, only using the last scale value so you'd have to add a more global state to keep the padding until the selection is dropped or changed as making it dissapear midway would be distracting).

Inkscape has a similar tactic which is to start rendering the resize elements outside the object limits but always touching their limits. This way you don't have padding amplification like in xournal, you don't loose in precision and you don't have issues with elements that are too thin.

Maybe switching from resize elements that are outside but resting on the boundary to the regular mode would be an acceptable idea ?

[Doublonmousse]

https://github.com/flxzt/rnote/assets/115779707/87cba4d0-50e0-48f7-aa6d-fe244ae8706c

Putting selection elements on the outside, changing the size limits to be around 1/100 of the view (we don't have collisions with the 4 rectangles for resizing elements, but we can have a collision with the (now outside) circle for rotation.

Although even in the worst case (the min stroke width on a horizontal element), as the rotating circle is on top, you still have a reasonable access to all controls

[Doublonmousse]

#1050 puts the selection handles outside and reduces the minium size (the previous minimum size was mostly calculated to prevent the handles from overlapping, which is less of a concern with the selection handles being outside now).

Maybe It'd be better to move the rotate handle to the side of the selection bound that's the largest to prevent the last overlap.

There is still some jumps to be expected selecting very small elements if they're too small relative to the zoom level. But at the same time allowing the minimum size to be too small and not related to the zoom level will be detrimental to the experience (as the min size is a global setting, wouldn't be fun to reduce an image too much that it's no longer visible !)