GLFW: some support for child HWNDs #4862
Conversation
screen to client coordinates if the target raw window is a child HWND
if the window is captured but not focused, because focus may belong to the parent of a captured child HWND
|
More information re b7a0d96: When a GLFW window is parented to a non-GLFW window, the initial mouse click is processed properly, but mouse capture is never established. This fails because underneath GLFW, Windows sets the FOCUSED attribute for the parent, not the child. ImGui requires the FOCUSED atrribute, so the mouse button state is not set. Instead we should set the mouse button state if the window has capture (mouse_window != NULL), regardless of whether another window in the immediate parent hierarchy has focus. [edit] the mouse issue is now moot, as per later comments in this thread. The positioning issue is still open. |
|
Sample use code, generally functional (though very basic) on windows and macos, using glfw/opengl backend: Plugins can generate multiple imgui windows/viewports, and embed them as children in non-imgui-aware parent windows provided by the host application. Mouse behavior on windows needs the mods in this fork, mac works fine off either the fork or the unmodified docking branch. Unrelated, the code renders imgui on main thread callbacks rather than in a closed run loop, since it's not running in the main application. |
|
I believe that 200a8f1 on dock 8000 ing has made b7a0d96 from this PR unnecessary. However I think that 9b14549 is still needed, and I have a similar patch for x11. I've synced this PR by reverting the now-unnecessary commit, merging the docking branch, and adding the x11 commit. The preferred fix would actually be in GLFW. |
|
Hello, Can you explain/confirm why this doesn't need to alter the equivalent getter |
|
Ping @schwaaa |
|
I believe the issue is that in GLFW's win32_window.c, _glfwGetWindowPosWin32() explicitly converts the returned coordinates from from client to screen, but _glfwSetWindowPosWin32() passes the input coordinates directly to win32's SetWindowPos(), which expects client coordinates for child windows. I haven't touched this code for a while so it's not top of mind, but if I have all the context right, the best fix would be to add some interface to GLFW so either setters or getters or both can specify whether they want client or screen coordinates. If we have to use GLFW as is, we need to handle the conversion ourselves. |
Translate window coordinates and handle mouse capture for GLFW windows that are child HWNDs. At present the only way GLFW windows can be child HWNDs is if the ImGui caller explicitly setparents them. See #4860 for the use case.