Fix tooltip behavior on tiling window managers

[Lukas1811]

As discussed in #708 the behavior of the tooltip on tiling window managers is buggy when "Appearance/Windowing/Viewport Mode" is set to "Multi window". When the tooltip would move outside the main window, the tooltip creats a secondary window, on tiling managers this leads to either a shift in window layouts or the creation of an opaque full container window since the tooltip is not correctly tagged as floating.

The addition from this PR forces the tooltip to be a child of the current windows viewport which fixes this issue by confining the tooltip to the to the confines of the current window.

The bavior was tested on i3wm and it seems to work as intended.

[azonenberg]

Having the tooltip extend outside the main application window is normal and desired on a non-tiling window manager.

More fundamentally, this same issue is likely to apply on all sorts of things like context menu popups (and other tooltips not just this one). For example, try right clicking on the filter graph canvas near the bottom of the window.

Disabling multiple viewports in the preferences is one way to work around this. I am not aware of any standard Linux API to determine if a tiling WM is in use, but we could perhaps use wmctl or ps to string-match known tiling WMs and disable multi-viewport by default if found (making the multi-viewport setting extend from on/off to on/off/auto, with auto as the new default)?

[Lukas1811]

You are right I found many other occurences of this behavior. It is actually also an upstream issue with ImGui not labeling tooltip windows correctly since they are labeled as _NET_WM_WINDOW_TYPE_NORMAL instead of _NET_WM_WINDOW_TYPE_TOOLTIP (just used xprop for inspection and I'm not sure about Wayland there).

When I find the time I will have a look at ImGui (I don't have any experience with it), I guess it's possible to have a clean solution there with multi viewport and tiling window managers.

For your suggestion of the 'auto' mode, the XDG_SESSION_DESKTOP env variable could be matched against a set of know DEs/WMs but that seems prone to errors. I'm also not aware of an API to determin the type of the WM.