audacious-media-player / audacious

A lightweight and versatile audio player
https://audacious-media-player.org
Other
817 stars 108 forks source link

Dock widget window-manager issues #1177

Closed Audacious-Bot closed 4 months ago

Audacious-Bot commented 4 months ago

Author Name: Jim Turner Original Redmine Issue: https://redmine.audacious-media-player.org/issues/1037 Original Date: 2020-12-04


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.

Thanks,

Jim

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: John Lindgren Original Date: 2020-12-05T04:53:27Z


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.

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: John Lindgren Original Date: 2020-12-05T04:54:27Z


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

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: John Lindgren Original Date: 2020-12-05T06:34:57Z


https://bugreports.qt.io/browse/QTBUG-89144

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

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: Jim Turner Original Date: 2020-12-05T17:41:56Z


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)?

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: John Lindgren Original Date: 2020-12-05T18:24:46Z


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.

Audacious-Bot commented 4 months ago

Original Redmine Comment Author Name: Jim Turner Original Date: 2020-12-05T22:24:11Z


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!

Regards,

Jim