frontend: Avoid hiding floating docks when the OBS app is not active on macOS

[TizianoCoroneo]

Description

This PR changes the behavior of floating docks on macOS to have them stay visible while the OBS app is not active.

The main change is to set Qt::WA_MacAlwaysShowToolWindow which sets the macOS' NSWindow.hidesOnDeactivate setting to false. This is enough to keep the docks visible.

Motivation and Context

In macOS, only one app can be "active" (aka "focused") at the time, and "floating panels" (OBS' docks in this case) disappear by default when their parent app is not active.

The issue is that disappearing floating panels defy many of the use cases that OBS is great for. For example:

• I'm doing game streaming on Twitch. I want to keep track of my chat.
• I have a floating panel displaying the "Twitch chat" dock on a side monitor.
• I click on my game, which becomes the active app. OBS is not the active app anymore, therefore the chat dock panel disappears.

This is a common issue between macOS users:

• https://obsproject.com/forum/threads/popped-out-docks-disappear-when-obs-is-not-in-focus.165011/
• https://obsproject.com/forum/threads/keep-dock-windows-visible-even-when-obs-is-not-in-focus.167324/

How Has This Been Tested?

I tested this change on my MacBook Pro M4 Pro, running macOS Tahoe 26.4.1.
Test by:

• open obs, float a dock.
• click on a different app to make it active.
• the floating dock should still be visible.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Tweak (non-breaking change to improve existing functionality)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
  I'm not sure what I'm supposed to do here. My PR targets the master branch, but I found no other indications of what to target otherwise.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[WizardCM]

What if we instead set Qt::WA_MacAlwaysShowToolWindow?

On macOS, show the tool window even when the application is not active. By default, all tool windows are hidden when the application is inactive.

By default, tool windows will disappear when the application is inactive. This can be controlled by the Qt::WA_MacAlwaysShowToolWindow attribute.

Source.

This should be functionally equivalent (it stops setting hidesOnDeactivate to true) and is supported by Qt directly.

[TizianoCoroneo]

Oooh good point. Sorry, it's my first time interacting with a QT codebase, I'm more familiar with Apple APIs.

I'll look into how to make this change soon 👍

[TizianoCoroneo]

Updated! Thank you again for your guidance

[MysticalOS]

<3 for this. I basically just gave up on pretending floating docks even existed on macOS for years now since they were effectively useless.

[WizardCM]

You should be able to simplify the code further, with just the singular setAttribute call within existing the inline OBSDock constructor and no other changes.

[mdwebbureau]

Awesome work, thank you for this!

[TizianoCoroneo]

@WizardCM fixed and verified it still works!

[PatTheMav]

I understand (and even agree with) the use case, but I'm also hesitant to accept this change, because the issue highlights a deeper issue:

Detachable panels (or "docks" as they are called in the code base) make sense for tool windows or other UI elements that can and should be detached for convenience (think the layers panel or tool selection panel in image editing software).

Such panels are foundational UI elements of their associated window and have no purpose outside of that window (the window is the "context" within which these panels operate).

So it does not make sense for these panels to stay visible when their associated window is hidden or minimised, which is also the reason for that being their default behaviour.

Indeed #13368 is an attempt to ensure the panels behave that way when OBS is set to "minimise to tray".

IMO the correct approach (and following the way we achieved the same with the stats window) is that these "panels" should indeed become independent windows that are not attached in any way to the main window and thus automatically have fully independent state.

The cop-out is of course to use this flag, but then I'd argue that some users would consider this behaviour the exact opposite of what they expect and now we'd need a setting for this. And then some people would want this behaviour to be enabled for some detached docks, but not others (so a global setting won't cut it), etc.

[mdwebbureau]

I understand (and even agree with) the use case, but I'm also hesitant to accept this change, because the issue highlights a deeper issue:

Detachable panels (or "docks" as they are called in the code base) make sense for tool windows or other UI elements that can and should be detached for convenience (think the layers panel or tool selection panel in image editing software).

Such panels are foundational UI elements of their associated window and have no purpose outside of that window (the window is the "context" within which these panels operate).

So it does not make sense for these panels to stay visible when their associated window is hidden or minimised, which is also the reason for that being their default behaviour.

Indeed #13368 is an attempt to ensure the panels behave that way when OBS is set to "minimise to tray".

IMO the correct approach (and following the way we achieved the same with the stats window) is that these "panels" should indeed become independent windows that are not attached in any way to the main window and thus automatically have fully independent state.

The cop-out is of course to use this flag, but then I'd argue that some users would consider this behaviour the exact opposite of what they expect and now we'd need a setting for this. And then some people would want this behaviour to be enabled for some detached docks, but not others (so a global setting won't cut it), etc.

Thanks for the explanation. I understand the concern that floating docks are technically still tied to the main OBS window, and that this may not be the perfect long-term solution from a UI architecture perspective.

That said, from a macOS user perspective this small change solves a very real daily problem. I personally use OBS with a detached chat dock while streaming, and before this change the dock disappeared every time I clicked another app. That made the floating dock almost unusable for my setup.

With this PR applied, the chat dock finally behaves the way I expected: I can keep it visible on my screen while working in another app, without losing sight of chat.

I agree that fully independent windows may be the cleaner long-term solution. But until that exists, this change is a very practical improvement for macOS users. Maybe it could be introduced as an option, for example per detached dock or as a global preference, so users who prefer the current behavior can keep it.

For my use case, this PR directly fixes the problem and makes OBS much more usable on macOS.

[TizianoCoroneo]

With this PR applied, the chat dock finally behaves the way I expected: I can keep it visible on my screen while working in another app, without losing sight of chat.

The chat dock is also my main use-case. While a per-dock setting would be of course preferable, I would probably still like the non-hiding behavior to be the default.

In general, users have other ways to hide floating docks if they really want to (just move them out of your way!). What is missing today is a way to avoid having floating docks automatically hide, completely ruining their usefulness in many cases.

I would still approve this change while investigating making floating docks full-fledged windows, so that users can also minimize them independently, for example. But still, this PR feels like a step in the right direction UX-wise, even if not implementation-wise.

[PatTheMav]

Thanks for the explanation. I understand the concern that floating docks are technically still tied to the main OBS window, and that this may not be the perfect long-term solution from a UI architecture perspective.

That said, from a macOS user perspective this small change solves a very real daily problem. I personally use OBS with a detached chat dock while streaming, and before this change the dock disappeared every time I clicked another app. That made the floating dock almost unusable for my setup.

With this PR applied, the chat dock finally behaves the way I expected: I can keep it visible on my screen while working in another app, without losing sight of chat.

I agree that fully independent windows may be the cleaner long-term solution. But until that exists, this change is a very practical improvement for macOS users. Maybe it could be introduced as an option, for example per detached dock or as a global preference, so users who prefer the current behavior can keep it.

For my use case, this PR directly fixes the problem and makes OBS much more usable on macOS.

The main issue is that OBS' code base is littered with a mountain of these little "fixes" bolted on to existing code to somehow coerce systems to do something they were never designed for instead of actually putting in the work to rewrite it.

It's "easy" insofar as it makes some users happy quicker, but it incurs a debt to the future (it literally is "tech debt") that makes it harder and harder to make meaningful changes to the program as a little change in one part of the program suddenly leads to collapses in seemingly unrelated parts of it.

Understand it as the "dark side of the force" if you will ("Quicker, easier, more seductive").