Coordinate systems

[madsmtm]

While doing #3890, I reviewed all our instances of [Physical|Logical|]Position, and categorized them relative to their origin point:

Desktop coordinates:

• MonitorHandle::position
• WindowEvent::Moved
• Window::outer_position

Window coordinates:

• Window::surface_position
• Window::set_cursor_position
• WindowEvent::Pointer*.position (from Implement the pointer event overhaul #3876) (maybe?)
• WindowEvent::Drag*.position (from Rework DnD redux #4079) (maybe?)

Surface coordinates:

• Window::set_ime_cursor_area
• Window::show_window_menu

MouseScrollDelta::PixelDelta is a delta, so it has no origin and hence no coordinate system.

I believe that we should make set_cursor_position, the pointer APIs and the DnD APIs use surface coordinates, since that's the easier coordinate system for users to work with.

[kchibisov]

I believe that we should make set_cursor_position and the pointer APIs use surface coordinates, since that's the easier coordinate system for users to work with.

it's not, it's easy as long as it matches pointer events, otherwise you'd have to convert back and forth all the time.

So, generally, coordinates in mouse events should be surface local, thus making all the set position stuff a surface local.

Window::show_window_menu is window coordinates, since it's a hint for system where to place menu over the window.

[madsmtm]

I believe that we should make set_cursor_position and the pointer APIs use surface coordinates, since that's the easier coordinate system for users to work with.

it's not, it's easy as long as it matches pointer events, otherwise you'd have to convert back and forth all the time.

It's more cumbersome to do things like hit-testing if the pointer position is in window coordinates instead of surface coordinates.

So, generally, coordinates in mouse events should be surface local, thus making all the set position stuff a surface local.

That's what I'm saying? As in, I agree that mouse/pointer events should be relative to the surface's top-left corner, not the window's top-left corner.

Window::show_window_menu is window coordinates, since it's a hint for system where to place menu over the window.

Idk what we are doing here, it's only implemented on Windows and Wayland, and I understand neither of those, I just took a guess from the Windows impl using ClientToScreen internally.

I think that, if we make everything else use surface coordinates, it might make sense to also make this use surface coordinates for consistency, regardless of how it works internally.

[kchibisov]

I think that, if we make everything else use surface coordinates, it might make sense to also make this use surface coordinates for consistency, regardless of how it works internally.

No, this API is only present for the top-level, top-level is a window coordinates, so any other coordinates don't make any sense.

You can pretty much figure out which coordinate system should be used based on whether subview/subsurfaces have them or based on the wording in the protocols.

In general, it would mean for both windows/wayland backend to convert from local to window coordinates which is not really trivial sometimes, and it doesn't make much sense...

Though if majority backends do surface local, then maybe we can use surface local as well...

[daxpedda]

I believe that we should make set_cursor_position and the pointer APIs use surface coordinates, since that's the easier coordinate system for users to work with.

Agreed.
This is already the case for Web.

We should also make sure that this is somehow clearly documented.