Winit 0.16 API changes

[icefoxen]

Just bits and pieces I'm stumbling across as I upgrade ggez, that come across as rough edges that should be easy to smooth. Maybe these have perfectly good reasons to be the way they are though, hence an issue rather than a PR.

• There's grab_cursor() and hide_cursor() methods on Window, but no methods to check whether the cursor is hidden or grabbed
• MouseScrollDelta::LineDelta provides (f32, f32) but MouseScrollDelta::PixelDelta gives a LogicalPosition which is (f64, f64)
• Is it possible to set custom mouse cursors via bitmap, or is that too platform-wonky?

[francesca64]

but no methods to check whether the cursor is hidden or grabbed

What's the use-case for this?

MouseScrollDelta::LineDelta

So you think it should be f64 for consistency? That would definitely be easy.

Is it possible to set custom mouse cursors via bitmap, or is that too platform-wonky?

This is actually probably easy to implement. The window icon API sets a precedent for how to expose it, too.

[icefoxen]

What's the use-case for this?

Paranoia that someone will ask for it. :-p

So you think it should be f64 for consistency?

Basically. It's not a big deal, just seemed odd that size and distance values were generally f64 except there.

This is actually probably easy to implement.

Awesome. I might give it a go sometime.

[icefoxen]

Another discovery: WindowBuilder takes the window sizes as LogicalSize. I want ggez to offer user the ability to manage their stuff using either logical or physical sizes. But we can't find the hidpi factor before we have a Window, which means we've already created it at a given size via WindowBuilder.

We can just create the window, query the hidpi factor, then resize it, so it's not a disaster (unless it's not resizable?), but it feels odd.

Edit for another thought: It might be convenient to be able to override the hidpi factor to something specific if we want to? We even have a hook to handle this in WindowEvent::HiDpiFactorChanged.

[francesca64]

Another discovery: WindowBuilder takes the window sizes as LogicalSize

Being able to create windows with physical sizes would be fairly trivial to implement on X11 and Windows. On macOS and Wayland, it involves inverting the hacks used for logical sizes on X11 and Windows. This means manually writing logic for resizing windows to desired physical size whenever they move across monitors/etc, while also updating the stored min/max dimensions and so on... along with the logic for guessing the initial DPI factor, and triggering an appropriate resize and corresponding events if said guess is wrong.

I keep telling people that they can solve any problem using a combination of linear scaling and scissoring (which is necessary anyway unless someone can make the guarantee the window will never resize, which is spoiler: impossible), but people seem to just want winit to do what they tell it to. While I have reservations about encouraging applications that don't respect the user's DPI (admittedly, it's only properly the user's DPI on Windows and Wayland), I'm not Apple the Supreme Goddess Dictator of Application Design, and I recognize that winit exists to serve the people.

But - and this is a very big but - I don't want to implement this. It should come as a surprise to no one, but I've burned myself out, and I'd like to put more time into my personal projects.

Edit for another thought: It might be convenient to be able to override the hidpi factor to something specific if we want to

Well, with the physical size logic above implemented, this would be easy to add on (given some refactoring to make everything link up nicely).

[icefoxen]

Hey, that's fine. Platforms differ on the "right" way to do things, so platform-compatibility hacks have to happen somewhere, I'm just glad that they're happening in winit. You've made it so that this is a problem I can solve via a combination of linear scaling and scissoring, so life is good. ;-) It's just a question of whether it's easier for it to be possible for that scaling to happen in winit. It sounds like it isn't; you need special cases either way.

I totally agree that things should be DPI-agnostic by default, but with ggez my hands are a little tied by the application domain. People writing pixel-y 2D things are usually going to expect one pixel in their sprite editor to be one pixel on the screen, and having to jump through hoops to make that be the case is going to make few people happy. So, I want to figure out the best way to do it, so we can ease people into a new paradigm bit by bit.

I'll dig a bit at the winit backend code. If I can find a nice way to query and/or set the DPI scaling factor before creating a window, or something like that, we can talk about it and I'll whip up a PR. If not, I'll just have to fake it with a window resize when the application starts and some conversions in ggez, which is kind of annoying but not a huge deal.