ocornut
Dragging secondary viewports out of main viewport
Version/Branch of Dear ImGui:
Branch: Docking
Back-ends:
imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp
Compiler, OS:
Linux + clang 19
Full config/build information:
Dear ImGui 1.90.9 WIP (19083)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=201703
define: __linux__
define: __GNUC__=4
define: __clang_version__=19.0.0 (++20240620031356+e3eb12cce97f-1~exp1~20240620151533.1757)
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000481
NavEnableKeyboard
DockingEnable
ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00001C0E
HasMouseCursors
HasSetMousePos
PlatformHasViewports
HasMouseHoveredViewport
RendererHasVtxOffset
RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1280.00,720.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00
Details:
When dragging a window either outside or inside the main screen boundary, it drops, necessitating a double-click to resume dragging.
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
ImGui::Begin("Test"); ImGui::Text("Hello World"); ImGui::End();
I forgot to mention, but I am using CMake to compile imgui to a library and then using it
are there any plans to add official CMake support for imgui?
Which version of GLFW are you using?
Currently the GLFW backend under systems other than Windows seems to be calling a different codepath, where it is possible that a combination of what GLFW does and what the WM does means you lose mouse inputs while dragging.
Please confirm GLFW version and open Tools->Debug Log->IO and capture IO log at the time of extracting a window into its own viewport.
With GLFW 3.3 we normally call:
glfwWindowHint(GLFW_FOCUS_ON_SHOW, false);
https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_glfw.cpp#L122C9-L122C41
And there's a workaround for older versions but it's Windows only: https://github.com/ocornut/imgui/blob/docking/backends/imgui_impl_glfw.cpp#L1128
I am using GLFW 3.5, I did notice imgui came with GLFW 3.3
[04951] [io] Processed: MouseButton 0 Up (Mouse)
[04951] SetActiveID() old:0xB89D6EE5 (window "Dear ImGui Debug Log") -> new:0x00000000 (window "")
[04952] [dragdrop] ClearDragDrop()
[04952] [viewport] Destroy Platform Window 8E350B18 'Dear ImGui Debug Log'
[04953] [viewport] Focused viewport changed 8E350B18 -> 11111111, attempting to apply our focus.
[04953] [viewport] Delete Viewport 8E350B18 'Dear ImGui Debug Log'
[04954] [io] Processed: AppFocused 0
[04954] [io] Processed: AppFocused 1
It seems to be destroying old window and creating a new window?
i forked on this commit: 7237d3e5c3a6b837b7b457460877cf5eea8c3745
video: https://media.discordapp.net/attachments/844849219504046154/1254947933447651348/imgui.webm?ex=667b58d7&is=667a0757&hm=d9aec2d766ce8380f9791afa297f3189d3c6db95eadbbe12ae3b37b8d9ec3b13&
The video link is invalid. I guess the question is to understand why you are getting the MouseButton 0 up event there.
At this point frankly I am considering to stop supporting multi-viewport under Linux since it's so complicated under this OS and we don't have any serious/focused contributor using Linux.
I think this is a duplicate of #3158, which links to an upstream issue in GLFW: https://github.com/glfw/glfw/issues/1562 With a potential fix here: https://github.com/rokups/imgui/commit/c510c112e081e334e06601302e5d9ca151ce62aa
Is that fix mergeable? I also see this on ImGui 1.90.8 under Linux/X11, so I'm happy to test things or work on improving that patch if you'd prefer a different fix. Multi-viewport support on Linux is critical for my usecase so I'm quite motivated to help out where I can :)
(though this particular bug doesn't personally bother me much)
At this point frankly I am considering to stop supporting multi-viewport under Linux since it's so complicated under this OS and we don't have any serious/focused contributor using Linux.
Multi viewport on Linux is key for ngscopeclient as well. We aren't super tightly tied to GLFW and I'm considering transitioning to SDL if these issues are upstream GLFW bugs with no easy near term workaround, but we absolutely do need it functional on one of the two.
As far as serious contributors go, the ThunderScope project (the first oscilloscope being designed with ngscopeclient as the official GUI) has publicly committed 50% of their profits to F/OSS they rely on. I've already asked for some of that budget to go towards Dear ImGui since it's such a core part of our workflow. I personally don't have time to do much ImGui work while also wearing my lead-dev-of-ngscopeclient hat, but if we can sponsor development efforts to make this work then we should definitely discuss.
i think multi-viewports requires a bit of a rewrite. Some of the issues i can reproduce on OSX now so I think I have that part more accessible to me, it’s just that I don’t have the brain time to focus on this soon. But I will eventually. And it’s just very difficult for me to trust external contributions since most of them have been hasty/flaky. So I don’t know how to solve that other than tell you to be patient.
i think multi-viewports requires a bit of a rewrite. Some of the issues i can reproduce on OSX now so I think I have that part more accessible to me, it’s just that I don’t have the brain time to focus on this soon. But I will eventually. And it’s just very difficult for me to trust external contributions since most of them have been hasty/flaky. So I don’t know how to solve that other than tell you to be patient.
We'll wait. At this point we're very close to a v0.1 feature freeze on our side (aiming for release by EOY), and it's too late in the cycle to do much about this other than "accept the quirks on Linux". Longer term, I plan to port from GLFW to SDL on the back end before v0.2 ships (some time next year).
We're running the docking branch and it's worked great for us except for this and the drag-and-drop bug (#7922) that both seem to be rooted in GLFW's per-window mouse handling on Linux.
It looks like an easy workaround in the backend. Rokups version of the fix (https://github.com/rokups/imgui/commit/c510c112e081e334e06601302e5d9ca151ce62aa) is too old now because backend logic has changed quite a bit with 1.87.
Could somebody submit a debug log with [X] IO and [X] Viewport checked?
I think the log https://github.com/ocornut/imgui/issues/7733#issuecomment-2187641947 is missing the part before the MouseUp and that's what we are missing just to confirm the order, but i'll work on a patch anyhow.
This is a log from v1.91.2 and GLFW 3.4.3:
[01037] [io] Processed: MousePos (3567.0, 868.0) (Mouse)
[01041] [io] Processed: MousePos (3568.0, 867.0) (Mouse)
[01076] [io] Processed: MouseButton 0 Down (Mouse) # Press the button and start dragging
[01095] [io] Processed: MousePos (3568.0, 868.0) (Mouse)
[01100] [io] Processed: MousePos (3567.0, 868.0) (Mouse)
[01101] [io] Processed: MousePos (3567.0, 869.0) (Mouse)
[01104] [io] Processed: MousePos (3566.0, 869.0) (Mouse)
[01115] [io] Processed: MousePos (3566.0, 870.0) (Mouse)
[01123] [io] Processed: MousePos (3566.0, 871.0) (Mouse)
[01128] [io] Processed: MousePos (3566.0, 872.0) (Mouse)
[01132] [io] Processed: MousePos (3566.0, 873.0) (Mouse)
[01133] [io] Processed: MousePos (3566.0, 874.0) (Mouse)
[01134] [io] Processed: MousePos (3566.0, 875.0) (Mouse)
[01137] [io] Processed: MousePos (3564.0, 876.0) (Mouse)
[01138] [io] Processed: MousePos (3564.0, 877.0) (Mouse)
[01140] [io] Processed: MousePos (3564.0, 878.0) (Mouse)
[01141] [io] Processed: MousePos (3564.0, 879.0) (Mouse)
[01142] [io] Processed: MousePos (3564.0, 880.0) (Mouse)
[01143] [io] Processed: MousePos (3564.0, 881.0) (Mouse)
[01144] [io] Processed: MousePos (3564.0, 882.0) (Mouse)
[01145] [io] Processed: MousePos (3564.0, 883.0) (Mouse)
[01145] [io] Processed: MousePos (3564.0, 884.0) (Mouse)
[01145] [viewport] Add Viewport 8E350B18 'Dear ImGui Debug Log'
[01145] [viewport] Create Platform Window 8E350B18 'Dear ImGui Debug Log'
[01146] [io] Processed: MousePos (3564.0, 885.0) (Mouse)
[01146] [io] Processed: MousePos (3564.0, 886.0) (Mouse)
[01146] [io] Processed: MousePos (3564.0, 887.0) (Mouse)
[01146] [io] Processed: MousePos (3564.0, 888.0) (Mouse)
[01146] [io] Processed: MousePos (3562.0, 889.0) (Mouse)
[01146] [io] Processed: MousePos (3562.0, 890.0) (Mouse)
[01146] [io] Processed: MousePos (3562.0, 891.0) (Mouse)
[01146] [io] Processed: AppFocused 0
[01146] [io] Processed: MouseButton 0 Up (Mouse)
[01146] [io] Processed: AppFocused 1
[01146] [viewport] Focused viewport changed 11111111 -> 8E350B18, attempting to apply our focus.
[01147] [io] Processed: MousePos (3562.0, 892.0) (Mouse)
[01147] [io] Processed: MousePos (3562.0, 893.0) (Mouse)
[01147] [io] Processed: MousePos (3562.0, 894.0) (Mouse)
[01147] [io] Processed: MousePos (3562.0, 895.0) (Mouse)
[01147] [io] Processed: MousePos (3562.0, 896.0) (Mouse)
[01147] [io] Processed: MousePos (3561.0, 897.0) (Mouse)
[01153] [io] Processed: MousePos (3561.0, 898.0) (Mouse)
[01155] [io] Processed: MousePos (3561.0, 899.0) (Mouse)
[01156] [io] Processed: MousePos (3561.0, 900.0) (Mouse)
[01156] [io] Processed: MousePos (3561.0, 901.0) (Mouse)
Thank you. @JamesWrigley @azonenberg @rakshitx1 @NicolasFirmo would you mind testing this untested patch for GLFW backend?
Can you confirm if changing bd->MouseIgnoreButtonFrames = 2; to bd->MouseIgnoreButtonFrames = 1; still fixes it or not?
That's not exactly the patch I would like to push as it assumes a certain time between creating window B and window A losing focus, but if it works I'll work on a slightly better one.
Great! Would you mind testing this variation? (remove previous patch, try this one) imgui-53609af-Backends GLFW V2 workaround for mouse button being released while creating a new window (3158, 7733, 7922).patch
I believe it is more correct and less strict in term of window unfocus timing.
I'll wait for another confirmation e.g. from @azonenberg to confirm this. Andrew does it fixes all the issues you had in #7922 ?
This was merged as c347d69. Thanks everyone for the help, and @rokups, and sorry for taking so long to look at this workaround.