Easier identification of ImGui windows on X11

[Ikos3k]

Version/Branch of Dear ImGui:

Version 1.91.7 WIP, Branch: docking

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp

Compiler, OS:

Linux i3wm (x11)

Full config/build information:

Dear ImGui 1.91.7 WIP (19163)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=201703
define: __linux__
define: __GNUC__=14
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000480
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigNavCaptureKeyboard
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,128
io.DisplaySize: 800.00,600.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:

My Issue:
Managing ImGui windows under i3wm (or other tiling window managers) is problematic because all ImGui windows either lack sufficient unique identifiers or share a generic WM_CLASS property. This limitation makes it difficult to apply specific window management rules, such as automatically enabling floating mode for docked ImGui windows. For example, in i3wm’s configuration file, users would like to apply a rule like:
for_window [class="ImGui"] floating enable
for_window [instance="ImGui"] floating enable

Proposed Solution:
ImGui could set a custom WM_CLASS property or another identifier for their windows on X11, allowing for easier and more precise window management in tiling window managers like i3wm.

Screenshots/Video:

2025-01-03.23-20-38.mp4

xprop output of ImGui docked window:

Minimal, Complete and Verifiable Example code:

ImGui::Begin("Example Bug");
ImGui::End();

[ocornut]

Hello,
I don't know how to implement this but it would be great it would largely help with #2117
A PR would be welcome.

[Madman10K]

I might have a clue to how we can implement it. Might also make a PR if we decided we want to include this functionality into dear imgui.

On X11 there is the WM_CLASS property. On Wayland there is an app ID, which is also a string. These variables are used as application IDs, rather than window IDs. This is because if an application spawns a child window, the child window should still be identified as part of the base application.

This means that we should be setting the same app ID for both the origin and all workspace windows, in order for them to be grouped correctly. However, what I can't really wrap my head around is whether we need to actually give unique identifiers to these child windows, and if we have to, how do we do it? To be honest, from what I know the task of remembering the position of a window is performed by the Session manager/Window manager so maybe setting some type of unique ID might help the session manager remember the window positions from the previous session. I might be overthinking it though, so it's best I research this.

As a side note, this is really useful for a lot of use-cases, specifically the way desktop environments manage taskbar icons. Though there is a way to set the application icon on X11/Wayland, many desktop environments ignore it in favour of using the icon from the application's desktop file. So an example application will first need to have a desktop entry like this:

[Desktop Entry]
Type=Application
Version=1.0
Name=example
Icon=example-icon
TryExec=example
Exec=example
StartupWMClass=example

with the StartupWMClass field set to the application ID, and then when launched it should register its application ID with the windowing system.

Anyway, these strings are set by the backend. For example, here is an X11/Wayland compatible way to set your Window ID in glfw, which I use in one of my applications:

#ifdef GLFW_PLATFORM_X11
    glfwWindowHintString(GLFW_X11_CLASS_NAME, applicationName.c_str());
#endif
#ifdef GLFW_PLATFORM_WAYLAND
    glfwWindowHintString(GLFW_WAYLAND_APP_ID, applicationName.c_str());
#endif

So the easiest solution would be to create a string field for such an ID in the backends configuration for GLFW, SDL2 and SDL3. There are a couple of questions that still stand, however:

1. We need to check how workspaces behave in these 3 backends, and whether we have to do something more for them to inherit the application ID for every child window
2. We need to do additional testing to see if we need to set any unique identifiers for each child window and try to think of an API to set them(might be needed for remembering window position from previous sessions)
3. We need to also consider whether this should actually included in dear imgui? Should part of this code be part of the third party backend libraries instead? What should and should not be set by dear imgui?

I will return with the required research on points 1 and 2 as soon as possible.