Implemented resizing for non-decorated winit windows

[LucFauvel]

Fixes #5023

Heavily inspired by these changes in Iced: iced-rs/iced#1542

Completely open to any changes, tested this on windows and works great but don't have any other environments at my disposal for testing yet.

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

Thank you very much for this patch.
Sorry for answering so late, but i was busy traveling during the week.

I'm just worried that this interact badly with eh contents of the window if there are some buttons or touch area near the edges.

[ogoffart]

for this pattern I'd have done a match (xdir, ydir) {
But this is fine too.

[LucFauvel]

Funny you mention this because I wasn't sure which pattern was better for readability after trying both. I'll commit this change and you can let me know which one you like better once you read it.

[ogoffart]

8 seems like a huge border.
I think it should be 1 or 2 logical pixel maximum. Don't you think?

[LucFauvel]

So I tried a few numbers and 3_f64 is the smallest I could go before I felt it started to get hard to hit it properly. Is that alright with you?

[LucFauvel]

@ogoffart

I'm just worried that this interact badly with eh contents of the window if there are some buttons or touch area near the edges.

Yeah I experimented with this and if, lets say, a toucharea is within the border, the cursor flickers as its being switched between the resize one and the toucharea one, but the resizing actually still works. Not sure how to fix it without breaking anything.

[LucFauvel]

I've added && window._is_resiable() to the handle_cursor_move_for_resize condition to prevent resizing if the user specifically disabled it.

[tronical]

I think this is a good feature to have, in general. More specifically though, the size of the resize border is something that should be configurable.

Imagine a custom UI of a media player (like Winamp back in the day), where the UI design conveys to the user where the borders are that can be used for resizing. This could be implemented visually through a nine patch image in Slint, and behaviourally this should be a property then on the Window. That's also the way of making it opt-in. Imagine a resize-border property that defaults to 0px. If it's non-zero, your code should become active.

What do you think?

[LucFauvel]

@tronical I agree that it should be configurable and thought about it in when first making this PR, I just wasn't familiar enough with the codebase to start adding options yet. Now that I am a bit more familiar I should be able to add it later today.

[LucFauvel]

@tronical @ogoffart As discussed above, I've added a property called "resize-border" to Window which configures the border. I've only done it with Winit since I don't have a working Qt setup atm.

Also I had some concerns while writing this, specifically this line that I've added: runtime_window.window_item().map_or(0_f64, |w| w.as_pin_ref().resize_border().into())

This creates a pinned refrence on every cursor moved event, is this a heavy operation that should be stored in the event loop state instead? Or is it light enough to not add too much additional memory pressure?

[ogoffart]

Thanks for the change.
Sorry for answering so late.

Since the property is a size in pixel, it should be a length value, so that its actual physical value depends on the scale factor.