I don't really like such an API, what's the use case for it? It seems like you wanted to pair it with the cursor position, but I think it's not a good thing to do.

Most times, it will be paired with cursor_position but another use-case for tauri users, is to center the Window on a specific monitor, so the users provide the x,y and we use it to detect the nearest monitor and center the window on that monitor, but why isn't it a good thing?

What I'd suggest is to add current_monitor on the EventLoopWindowTarget, so you can get the currently focused monitor on the system, since that's all that matters and what you want anyway.

Most cases yeah but there is a chance you may need other monitors.

Most times, it will be paired with cursor_position but another use-case for tauri users, is to center the Window on a specific monitor, so the users provide the x,y and we use it to detect the nearest monitor and center the window on that monitor, but why isn't it a good thing?

But you can least monitors and provide user to pick a monitor? Winit allows setting fullscreen on any monitor and you have them available on the event loop.

But you can least monitors and provide user to pick a monitor?

by tauri users, I meant developers, not end-users.

We had a little discussion regarding units across multiple monitors in #2645. Short version: I don't think using PhysicalPosition for coordinates across multiple screens makes sense, though that is currently what other APIs use.

The thing is that coordinate space system is using could be negative, don't match, and so on.

I think that there's no value in such API, given that we should use either None(let the system decide) or provide exact monitor (from `available_monitors').

The API with the points will be very limited and will add much complexity given that:

1. Not supported by most display servers.
2. Coordinate space could have negative values (at least on Wayland and it'll require custom protocols, yet you have no information where your cursor is), so the API need some restrictions.

My main issue is that lack of use case for such an API, since if you want a current monitor, right now you pass None to all APIs accepting output, and you'll get it. If you want a particular monitor you just pass a particular monitor. The location of outputs relative to each other is not that established concept (It's not even a rectangle shape to begin with).

My main issue is that lack of use case for such an API, since if you want a current monitor

I agree with that to an extent, the use case is very much rare so I don't really want to push hard on this since the functionality could be implemented in user code by iterating over the available monitors and comparing its bounds with the point.