ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
MIT License
59.56k stars 10.15k forks source link

Linux/GLFW: Dragging a window via OS decorations messes up hover detection #2950

Open Folling opened 4 years ago

Folling commented 4 years ago

Version: 1.74 Branch: docking

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp Compiler: Clang 9 Operating System: Arch Linux 64 bit - with KDE Plasma as my desktop environment

When dragging from the native window bar, Dear ImGui's detection of the mouse pos seems to get messed up. I can verify that this happens under linux with glfw+opengl3, though I haven't tested it under other circumstances.

Here's a video demonstrating the issue, to give a better understanding of what I mean: https://www.youtube.com/watch?v=OGIpU-Z3uGw&feature=youtu.be

    if(ImGui::Begin("Bug Test")) {
        static std::string s{};
        static float fa[4];
        static float f{};

        ImGui::InputText("Test", &s);
        ImGui::ColorEdit4("Test2", fa);
        ImGui::Button("Test3");
        ImGui::DragFloat("Test4", &f);
    }
    ImGui::End();
rokups commented 3 years ago

SDL is also affected by the way. This happens because X11 does not report new window position during drag operation. Only when mouse button is released X11 sends ConfigureNotify event with updated window position. However we get mouse position updates real time. So during duration of drag operation imgui thinks that main viewport remains in it's original position, however mouse seems to have moved over these elements and thus we see mouse-over effect rendered. I am not aware of a way to fix it (neither on our end, nor on SDL/GLFW end) given how currently imgui works. The only way around this would be to rearchitecture docking branch to not care about global window positions, however this is a huge and complicated discussion in itself.