Bug #1037

Dock widget window-manager issues

Added by Jim Turner 11 months ago. Updated 10 months ago.

Target version:
Start date:
December 04, 2020
Due date:
% Done:


Estimated time:
Affects version:


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 11 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.

#2 Updated by John Lindgren 11 months ago

As a workaround, I'd suggest keeping plugin widgets docked in the main window -- that solves pretty much all window management issues.

#3 Updated by John Lindgren 11 months ago

  • % Done changed from 0 to 100
  • Category changed from libaudqt to plugins/qtui

I added a workaround to the Qt UI. Please test and see if it works for you.

#4 Updated by John Lindgren 11 months ago

  • Status changed from New to Closed

#5 Updated by Jim Turner 11 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)?

#6 Updated by John Lindgren 11 months ago

Sounds like a different bug. For this one you specifically said, "When Audacious is started with a given dock widget inactive". So please open a new ticket with details and exact steps to reproduce.

#7 Updated by Jim Turner 11 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!



#8 Updated by Thomas Lange 10 months ago

  • Target version set to 4.1

Also available in: Atom PDF