rust-windowing
Add `cursor_position` getter API
- [x] Tested on all platforms changed
- [X] Windows
- [x] macOS
- [X] X11
- [X] Added an entry to
CHANGELOG.mdif knowledge of this change could be valuable to users - [X] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
- [X] Created or updated an example program if it would help users understand this functionality
- [X] Updated feature matrix, if new features were added or implemented
What's the motivation for getting the cursor position with the new function over getting it via an event ?
This is useful for positioning the window on a particular monitor when creating the window, for example, when making a spotlight-like app, where you want to show the window on the monitor the has the cursor, then I would need to:
- get the cursor location
- get the monitor based on the cursor location
- center the app on the monitor
This PR is for 1 and I will be opening another PR for 2, later today or tomorrow.
get the cursor location get the monitor based on the cursor location
This won't work on macOS/Wayland for sure?
for macOS there is no direct API to get a monitor based on a point but we can iterate over available monitors and check if the point is contained within one of them
Wayland yes, macOS should be possible, no?
On Wayland certainly not. Since you know only about the cursor over your window. You don't even have control were to open a window, so use-case you're describing is very specific and can be achieved on X11 and maybe Windows.
And in my experience normal window managers will open a new window where your cursor is if you don't explicitly specify the output you want(like on Wayland it's done by majority).
yeah mostly you don't need to manually position your window but there is use-cases where you want to control which monitor to spawn the window on, for example: spotlight-like apps, widgets, overlays...etc
But you already have all in-place for that? You could just report current_monitor on the event_loop or such?
On Wayland certainly not. Since you know only about the cursor over your window. You don't even have control were to open a window, so use-case you're describing is very specific and can be achieved on X11 and maybe Windows.
You should be able to implement a centered "spotlight-like" app like this on Wayland with layer-shell (in compositors that support it), but yeah, you couldn't implement it this way.
This is useful for positioning the window on a particular monitor when creating the window, for example, when making a spotlight-like app, where you want to show the window on the monitor the has the cursor, then I would need to:
1. get the cursor location 2. get the monitor based on the cursor location 3. center the app on the monitorThis PR is for 1 and I will be opening another PR for 2, later today or tomorrow.
May be you can keep 1 private for 2 ?
May be you can keep 1 private for 2 ?
2 has been rejected in https://github.com/rust-windowing/winit/pull/2649 so this API is no longer connected to 2 directly
As I mentioned earlier, the "spotlight-like app" use case on Wayland would be served by layer shell (https://github.com/rust-windowing/winit/issues/2582). I think what would be ideal for that is if either winit or an extension crate could provide an API that can use layer shell, or position things more manually on X/win32/etc. to provide as portable a solution as possible for this particular use case.
I would generally agree with the authors of the base Wayland protocol that applications placing windows at specific spots on screen is generally a bad practice outside of specialized things like this (though Winit already has set_outer_position).
https://github.com/rust-windowing/winit/issues/2160 is relevant, wrt including things in winit vs a separate crate.
Seems like a couple of tests are failing on nightly but should be unrelated to this PR