[podulator]

This resolves the first half of #359: Window::suggest_fallback_scale_factor() now returns a Result<bool, Error>.

true means the fallback is now the scale in use, and false means the platform already had its own value, and uses that.

This lets a plugin wrapper answer the host truthfully: CLAP's clap_plugin_gui::set_scale is documented to "override any OS info" and to return false if the call is ignored, but baseview previously always reported success even when its Xft.dpi/system value took priority over the host's suggestion. The bundled CLAP examples are updated to show the intended use (propagate false as an error, since clack's PluginGuiImpl::set_scale has no other way to say "ignored" yet).

It doesn't change the X11/Win32 priority logic itself (the host overriding the platform for embedded windows) - that's the discussion in #359 (comment).

The API change means that ? style callers still compile, but code that returns the call's result directly from a Result<(), _> function won't. So, it is a small breaking change, and it might want to go in a v0.5?

It's tested on X11, but could use a real world Windows and Mac test, really.

[prokopyl]

This PR looks good to me, but you are correct, it is a breaking change, so it'll have to be released in the next major version of baseview.

Would you mind rebasing your work on the next branch instead of main? That way it'll be released as part of 0.5 (which is already being worked on).

Be aware however that the X11 implementation has changed quite a bit (see #357), however it should make your changes simpler since you won't need to send a request to a separate thread anymore. 🙂

[podulator]

Ok, rebased onto next, thanks!
You were right, it was simpler than previous version on main. With the X11 thread gone, the value is simply returned, no extra enum needed.
HostedWindow::suggest_fallback_scale_factor() in baseview-host returns bool too, so both APIs say the same thing.

One thing I noticed, next doesn't have the #358 fix yet (it landed on master after next branched), so on next a second suggested scale still compounds with the first. I've left it out of this PR, since I guess it comes with the next master → next merge, but I'm happy to send it as a separate PR against next if that helps.....

Cheers