For me under Xfwm4, get_position and get_inner_position return the same values. However, since that's the result of more fundamental issues with geometry calculation in the X11 backend, I think it's fine for now.

I just tested this on macos 10.12.4 by printing the result of window.get_position() and widow.get_inner_position() within the event loop of the window.rs example and watching the values as I move the window around. Both methods produce the same result which seems to be the "outer" position (top left of the decorations).

Not sure if the get_inner_position mac implementation should be fixed or not before this is merged. Perhaps at least it could be changed to unimplemented!() in the meantime to avoid weird unexpected behaviour issues?

Okay, with #438 merged, this works on X11 now.

@mitchmindtree are you sure they were both outer position? I changed the relevant code (and badgered one of my friends into testing it), and it seems that the existing get_position implementation was returning the content area position (judging by both the values returned and the use of contentRectForFrameRect). So, I changed get_inner_position to be identical to the current get_position, and changed get_position to just use the frame rect instead of requesting the content rect.

(Also, it seems that on macOS, set_position sets the content area position. On X11, we set the outer window position, and I'm not sure about the other backends, but that's a concern for a separate issue.)

EDIT: the set_position implementation appears to be informed by that incorrect get_position implementation, and it would be easy to fix: https://github.com/tomaka/winit/blob/591e0d9b8e9f93675c25c70acea846a5d50dae46/src/platform/macos/window.rs#L543-L547

Okay, set_position works the same way on Windows as it does on X11, and the docs specify that set_position uses the same coordinates as get_position. I've corrected the implementation of set_position on macOS accordingly.

@RobSaunders do you think you could take a look at this?

Alright, after getting a chance to test this on macOS hands-on, I've confirmed that the new implementation is correct, and consistent with Windows and X11.