Add new EditorHandle::default_scale function

[emuell]

Follow up of #10.

This adds:

• Window::os_screen_scale() to query the main screen's default scaling, using the backing factor on macOS, LOGPIXELSX info on Windows, and screen height_in_pixels/millimeters ratio on Linux.
• EditorHandle::default_scale(), which plugin editors can use to initialize default canvas scaling.

So, this only provides a default value for editor scalings. Hosts will override this in most cases.

But when hosts don't set scaling, this sets a somewhat sensible default. And when hosts do set a scaling, this avoids that the plugin window gets resized and rebuilt in case the host's scaling matches the default screen's scaling - which is very likely.

I've also added a few more comments for the Windows platform info, trying to make clear why no DPI scaling is used there.

We already discussed this topic. Totally fine with me in case you don't want such a default scaling and rely on scaling info from hosts only. I'll keep that in my fork then. But I think it doesn't hurt, but just helps in edge cases.

[ilmai]

I like this idea in principle but there are a couple of problems:

• Drag & drop coordinates are now wrong on Windows when the window is scaled since you removed scaling (still not sure why they need to be scaled at all, I haven't had time to look into it)
• Having os_screen_scale() in addition to os_scale() feels wrong; maybe they should be combined and then based on platform decide where they need to be used or not (in the new default_scale() function and within plugin-canvas-slint basically)

I have some more specific comments as well but I wanted to resolve these issues first. Also note that there will be some conflicts with the mouse event pre-scaling code as well.

[emuell]

Drag & drop coordinates are now wrong

There is no scaling applied on the OS window level on Windows and Linux: fn os_scale(&self) -> f64 always returned 1.0 here. The only thing I did was commenting this and removing the scale(1.0) to make that clear.

Having os_screen_scale() in addition to os_scale() feels wrong

It's confusing, yes, but it's two different values for different purposes - so it also should be two different functions.

But yes, this whole topic is confusing, especially because it works different on macOS, but that's ugly either way. My old approach to apply the OS scaling on all platforms caused confusion on other sides. But you do have a better overview here, so there indeed might be a better approach to deal with the platform differences here.

[ilmai]

There is no scaling applied on the OS window level on Windows and Linux: fn os_scale(&self) -> f64 always returned 1.0 here. The only thing I did was commenting this and removing the scale(1.0) to make that clear.

Ah yeah scratch that, looks like drag and drop coordinates are already broken at the head of main, will have to fix that separately

[emuell]

Exactly. #17 was my attempt to fix that, but now is obsolete. Still think os_scale (usage) should be removed on Windows and Linux because it's always 1.0 by design now.

[ilmai]

Figured out that an earlier change where os_scale() now returns 1.0 on Windows broke drag & drop coordinates; ScreenToClient indeed doesn't seem to be DPI-aware for some reason so the OS scale does need to be applied there. There are now enough conflicts between this branch and main that I think I'll just redo your suggested changes (and the os_scale/os_screen_scale() unification) from scratch. Thanks for the suggestion and your work!

[emuell]

I'm confused now. Why is there a OS scale on Windows now?

Drag and drop worked just fine here, after applying the slint canvas scaling. Which was expected and exactly what my fix was about.

In DPI aware apps on Windows, all positions, sizes, mouse positions, and drag & drop coordinates are pixels. There's no need to apply Windows' DPI scaling. The scaling that gets applied by the host is applied as slint canvas scaling. So it should also be applied on the slint level IMHO.

Where it gets extra confusing on Windows is when an app is marked as DPI unaware. The all those positions and sizes will get magically upscaled by Windows. But this is consistent too, as the host would then also apply no extra scaling. There still is no need to apply some DPI scaling then.

Anyway. Let me know if you are interested in the default scale thing, then I'll create a new patch. As mentioned before I also have no problem keeping this in my fork.

[ilmai]

If it helps, I'm confused too. I'm aware of how it should work but ScreenToClient was returning incorrect coordinates before the change and the change grew bigger as the window was moved away from the top left window, indicating that it's an issue with the screen coordinates being incorrectly scaled.

Since Slint doesn't officially support drag & drop yet, I'm also sending a mouse move event whenever there's a drag move event. If you try before and after the change on Windows and make an element follow the mouse cursor in Slint, you can see before the manual DPI scaling there was a difference between regular mouse events and drag events.

Anyway I've now implemented the default scale thing, although I made it a global function called screen_scale()

[emuell]

If it helps, I'm confused too. I'm aware of how it should work but ScreenToClient was returning incorrect coordinates [...]

Maybe that happens on multi monitor setups with different scalings only? I can't replicate that here on single monitor setups with whatever scaling.

Anyway I've now implemented the default scale thing, although I made it a global function called screen_scale()

Thanks!

plugin-things/examples/gain-plugin/src/editor.rs

Line 15 in 5e4c468

scale: screen_scale(),

This should be 1.0 on macOS. Adding a EditorHandle::default_scale(), as proposed in this PR, could make that clearer and easier to use, and also avoids publishing screen, which else isn't really needed.

impl EditorHandle {
    pub fn default_scale() -> f64 {
       // On macOS the system's window backend scaling gets automatically applied.
       #[cfg(target_os="macos")]
       {
           1.0
       }
       // On Windows and Linux the window backends do not use the system's DPI settings, but rely on the host to provide scaling values. Use the default screens scaling by default.
       #[cfg(any(target_os="windows", target_os="linux"))]
       {
           screen_scale()
       }
    }
}

I promise I won't nag you about scaling anytime soon :) Works great now.

[ilmai]

Maybe that happens on multi monitor setups with different scalings only? I can't replicate that here on single monitor setups with whatever scaling.

I have just one monitor, no idea what's going wrong.

Anyway I added Window::default_scale() that doesn't use screen_scale() on Mac, good call. And no worries about nagging, this is complicated and it's good to get it right even with some confusion on the way.