Dock widget window-manager issues
When Audacious is started with a given dock widget inactive (that starts up floated when activated), then when the widget is first activated, the newly-floated window seems to be in window-manager limbo. It is stuck on top (of all windows) such that clicking to focus on a non-Audacious window will not cover it. Also, in the case of the equalizer window, it has focus until you click elsewhere, and will not accept focus or raise (by mouse-click or window-manage command) after losing it (This does not seem to be the case with other non-plugin widgets: playlist manager and queue-manager). These issues remain until one clicks the little title-bar button to dock it, then again to re-undock (float) it, in which case it will work properly until Audacious is shut down and restarted. I don't know what goes on when "undocking" a window, that isn't happening when the window is first created, but please investigate / fix.
I tested on recent linux Qt v5.15.1-2 and 3 different WMs: Afterstep, fluxbox, and icewm, all using "Click-2-focus" model, with same issue(s).
Steps to reproduce:
1) Launch Aud with no eq or plugins.
2) Launch Lyrics, playlist mgr, or equalizer, etc. (dock window has kb focus as it should)
3) Drag it over somewhere on the screen.
3) Click on a non-Audacious window (raising it & giving it kb focus) that is underneith. It focuses & raises, but is still underneith the offending plugin window (should be on top now).
4) Click back to the plugin window, it will not take kb focus. Issue WM focus, raise, or promote layer to offending window - no effect.
5) Dock the offending window.
6) (re)Undock it. It returns properly to it's previous position, and now works properly / as expected, obeying all WM events now.
#1 Updated by John Lindgren about 2 months ago
I can reproduce the "unwanted always-on-top" issue (Qt 5.15.2 and openbox). It seems that Qt is creating the plugin window with different hints when this occurs, because it doesn't show up in the Alt-Tab switcher either.
Please report this as a bug to Qt. The creation of the separate plugin windows is entirely done by the toolkit in this case (unlike in GTK where we do it ourselves) and we don't have control over what hints they are created with.
#5 Updated by Jim Turner about 2 months ago
You closed this whilst I was still testing?! This workaround fixes alot of things! The only thing it DOESN'T FIX is when Audacious is started with a plugin window already floating. Is there ANOTHER place in the code that this workaround needs to also be added? (When active plugins are started on Audacious startup)?
#7 Updated by Jim Turner about 2 months ago
After further testing, you are correct in closing. The only remaining issue I described is only for my rickedy ol' AfterStep "window-mangler" of mine, and the solution there was to configure it to put all Audacious windows onto "Layer 0", but also "HonorGroupHints, HonorTransientHints, HonorExtWMHints" (to prevent AS from defalut-placing these windows to layer 1 (to force them on top of the main Audacious window) - AS, with all it's warts (the author was a "Unix / focus-follows-mouse" guy), allows you to configure that kind of stuff on an app-basis! The other WMs I tested seem to work great with your "workaround", so with that, I consider this issue "CLOSED".
Thanks again John for looking at this with me and for the workaround!