fix(macos): treat Monitor::from_point args as physical

[dgerhardt]

The x and y values passed to from_point are now treated as physical and therefore converted to logical values on macOS. This makes the behavior consistent with the Windows implementation.

Closes tauri-apps/tauri#12676.

[github-actions[bot]]

Package Changes Through 45236e432c68bd8b76b37e1248174263befb31c9

There are 1 changes which include tao with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tao	0.32.3	0.32.4

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[dgerhardt]

This seems to be a tricky situation. Adjusting the behavior might be a breaking change for some users but at the same time I think that from_point can't be used for cross-platform development at all in its current state. At least not without applying your own workarounds which check for the OS. Also, most of TAO's API uses PhysicalPosition as return type, so you still would need to explicitly convert the type in many cases on macOS.

Using Position for the parameter sounds like a good solution which would also be more consistent with the rest of the API. Maybe we could introduce a new from_position method and deprecate from_point for a smoother transition?

[FabianLars]

Maybe we could introduce a new from_position method and deprecate from_point for a smoother transition?

with tao being 0.x this imo doesn't really matter unless we simply prefer one name over the other.

[lucasfernog]

let's just document that monitor_from_point takes logical values on macOS and physical on other platforms, and add monitor_from_position

[amrbashir]

we can just remove it altogether and release a minor for monitor_from_position, only tauri will need deprecation.

[someone2080]

It looks like this is not the only function that works with logical values instead of physical ones on Mac. Look at #1023.

In this case, I think updating the docs and deprecating the existing methods that are inconsistent between platforms in favor of creating new ones in the next versions would be a more preferable approach for many users.