GLFW3.4+ on X11: copy the WM_CLASS property from the parent window for viewports

[Madman10K]

This PR resolves one of the issues listed in #8289. The issue should not be closed, because this PR does not fix all the issues that are still needed to be resolved to mark the PR as complete. I hope to resolve #8289 in followup pull requests in the near future.

This patch makes it possible for dear imgui to copy the WM_CLASS property of a window under X11 when compiled with GLFW version 3.4 and later.

This PR does not fix the following:

1. The Wayland app ID not being copied or set(GLFW does not set a default app ID)
2. Making it possible to differentiate between viewports when configuring tiling window managers in both X11 and Wayland

However, it does fix a number of issues, such as:

1. Viewport windows being treated as separate applications by various desktop environment features
2. Even though differentiating between viewports and the root window/s of the same application is not implemented here, it does allow for differentiating between viewports of other dear imgui applications

Unfortunately, to make this PR possible, the implementation uses the native X11 API, due to GLFW not implementing any method of getting the value of window hints or of its internal structures :/

Testing

Tested this under latest Arch Linux, Ubuntu Linux 24.10 and Ubuntu Linux 24.4. Due to the unavailability of GLFW version 3.4 in Ubuntu 24.04 this patch will not be covered by our Linux CI correctly unfortunately :/

[Ikos3k]

I tested the example_glfw_opengl3 on Arch Linux (kernel 6.13.5-arch1-1), and it works well. However, I believe it would be better to hardcode the ImGui window name into the class name or instance, rather than deriving it from the title of the main GLFW window.

Here’s a snippet from my i3 configuration file (each of these rules works):
$ cat .config/i3/config | tail -n 4

# for_window [title="Dear ImGui GLFW"] exec --no-startup-id notify-send "test1"
# for_window [class="Dear ImGui GLFW"] exec --no-startup-id notify-send "test2"
# for_window [class=".*ImGui.*"] floating enable
for_window [title=".*ImGui.*"] floating enable

[Madman10K]

Deriving the name from the title of the window is something that we cannot change. The creator of the application can set the platform hints for the WM_CLASS property, however if these hints are not set for some reason, GLFW defaults to the window's title. What we can do, however is get the WM_CLASS property, regardless of how it's set and set it for all windows spawned by dear imgui.

Changing the WM_CLASS of viewport windows will change how they are treated by other desktop environments/window managers. They will be shown as 2 separate applications which is not what we want.

I thought I could add something like dear imgui to the instance property of WM_CLASS, however it turns out that desktop environments like GNOME distinguish between instances and show the same application 2 times, though in this case, since the class is set correctly they are treated as the same application, unlike in the previous case.

In my opinion, appending ImGui or anything else to the title is also not ideal, since it will be weird, especially for windows that are not outside the boundary of the root window.

I don't really know what the solution for this is, except maybe adding the _NET_WM_TRANSIENT_FOR property to point to the root window, however this will have other side effects:

The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of another top-level window. The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction. Dialogue boxes, for example, are an example of windows that should have WM_TRANSIENT_FOR set.

It is important not to confuse WM_TRANSIENT_FOR with override-redirect. WM_TRANSIENT_FOR should be used in those cases where the pointer is not grabbed while the window is mapped (in other words, if other windows are allowed to be active while the transient is up). If other windows must be prevented from processing input (for example, when implementing pop-up menus), use override-redirect and grab the pointer while the window is mapped.

Also, let's suppose the _NET_WM_TRANSIENT_FOR property is set - I don't know how many window managers actually support setting rules against this property. For example, there is nothing in the i3wm's documentation that mentions applying rules for such windows.

That is the reason this PR is a partial fix. I really don't know how to fix this for tiling window manager users right now.

There is still a big benefit to fixing this for DE users, even if tiling window manager users are still left without good support. My plan is to fix this for tiling window managers when I find a good method to fix it(and get more experience with programming for X11)

[ocornut]

FYI merged 6b2cdf2 + minor tweaks 37b18ac from #8884, which seems to resolve the X11 side of this although there are open questions here. I left a comment about Wayland + link to here from the code. What do you think we should do about this commit?
@Madman10K do you generally agree with merged commit?

[Madman10K]

@ocornut I have some concerns about the window types being changed. Link to the window manager specification

The specification simply lists these hints and vaguely defines what they mean but it does not force window managers to comply to any set of guidelines. What we're doing here is that we're hoping that the window manager will treat the viewport windows as if they are dialog boxes which may or may not include any number of restrictions to window stacking, selection, decorations and more.

I am mostly concerned about a couple of UX issues that are likely to occur:

1. WMs start drawing viewport windows as modals which can make them unusable
2. Having window decorations drawn even when we explicitly disable them
3. Viewport windows being always-on-top, even if clicked away from
4. Being unable to be minimized
5. Viewports windows not showing in the window overview mode(or the pager) on desktops like GNOME(Pressing Win/Super to show all the windows/desktops)
6. Automatic recentering of the window
7. Resizing might be disabled

I think this needs more testing but I doubt that going the path of window hints is the correct decision in this case. Considering the possible risk I think that the best decision would be to revert this commit for now and when we at least have proof that setting this window hint will not go against the expected user experience on popular desktop environments(GNOME, KDE, XFCE, LXDE, LXQt) we can safely merge it back.