UI: Remove unnecessary ProxyStyle usage

[Warchamp7]

Description

This removes an unnecessary usage of QProxyStyle for the source context bar media QSlider and the destruction/recreation of audio mixer controls.

Motivation and Context

It appears we abused the styleHint approach of using SH_Slider_AbsoluteSetButtons which causes it to treat clicks in the slider area as absolute points to jump to. While it works, this is meant to be a style implementation, such as an OS difference.

Instantiating a new custom style just for this slider does not seem to be a proper usage of styleHints, and due to our heavy usage of QSS which is itself a QProxyStyle, causes some weird behaviour we've worked around in places.

Instead, this slider now handles the actual mouse events to perform the same behaviour, without having to force an update of the context bar.

Additionally, work in #9653 appears to have solved the need to completely destroy and recreate the Volume Controls on theme change.

How Has This Been Tested?

Built OBS. Used the context bar slider for media sources. Swapped themes a bunch.

Types of changes

• Tweak (non-breaking change to improve existing functionality)
• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[RytoEX]

I'm not sure what the Volume Control changes have to do with the rest of the PR:

UI: Remove ProxyStyle for context bar media Slider

I feel like this should either be two commits with a rescoped PR description/title or two PRs:

1. Media Slider
2. Volume Control

[Warchamp7]

Commits have been adjusted. Will need testing on mac/Linux and testing at different scaling to ensure the mouse logic is solid.

[gxalpha]

Just to have it written on the PR:
The proposed alternative to the custom absolute click handling would be SH_Slider_AbsoluteSetButtons on OBSProxyStyle, personally I'd prefer that over custom handling, especially since it appears that native Windows sliders also behave that way.

[RytoEX]

Just to have it written on the PR: The proposed alternative to the custom absolute click handling would be SH_Slider_AbsoluteSetButtons on OBSProxyStyle, personally I'd prefer that over custom handling, especially since it appears that native Windows sliders also behave that way.

I've been unable to find a slider in Windows 11 that behaves otherwise. The native volume, brightness, and text size controls all move the slider exactly where I've clicked. None of them have any stepping behavior. Maybe it was this way in Windows XP/Vista? I'm more shocked that apparently no one has filed a QTBUG over this particular behavior.

[RytoEX]

I've been unable to find a slider in Windows 11 that behaves otherwise. The native volume, brightness, and text size controls all move the slider exactly where I've clicked. None of them have any stepping behavior. Maybe it was this way in Windows XP/Vista? I'm more shocked that apparently no one has filed a QTBUG over this particular behavior.

Just for visibility, I filed QTBUG-125154 for this, at least for their new Windows 11 style in Qt 6.7. All the native Windows 11 sliders and WinUI 3 slider examples I found moved to absolute position on left-click or snapped to the nearest tick (the former is default behavior, but the latter can be configured).

[RytoEX]

Just to have it written on the PR: The proposed alternative to the custom absolute click handling would be SH_Slider_AbsoluteSetButtons on OBSProxyStyle, personally I'd prefer that over custom handling, especially since it appears that native Windows sliders also behave that way.

For what it's worth, I mentioned off-thread that I would also be fine with this. We actually already do OS-specific stuff in the styleHint call in OBSProxyStyle, so we could ifdef it for Windows if we were inclined (I don't know what "expected" slider behavior is on Ubuntu/Linux/etc.):

obs-studio/UI/obs-proxy-style.cpp

Lines 86 to 89 in af685be

	#ifdef __APPLE__
	if (hint == SH_ComboBox_UseNativePopup)
	return 1;
	#endif

If the primary things that we want are in the refactoring commits (the first two), we could split the third commit off and deal with that question later. Not sure how troublesome that is (if code in #10625 relies on the third commit).

In a worst case, we can merge this as-is and reconsider the implementation (OBSProxyStyle vs. events) later.

[RytoEX]

I've been unable to find a slider in Windows 11 that behaves otherwise. The native volume, brightness, and text size controls all move the slider exactly where I've clicked. None of them have any stepping behavior. Maybe it was this way in Windows XP/Vista? I'm more shocked that apparently no one has filed a QTBUG over this particular behavior.

Just for visibility, I filed QTBUG-125154 for this, at least for their new Windows 11 style in Qt 6.7. All the native Windows 11 sliders and WinUI 3 slider examples I found moved to absolute position on left-click or snapped to the nearest tick (the former is default behavior, but the latter can be configured).

Following up on this, I double checked the slider examples in the WinUI 3 Gallery on Windows 11 and all of them have the default behavior to set the absolute value of the slider to the StepValue nearest to the position clicked. If the StepFrequency is 1 (the default), this is indistinguishable from "left-click sets absolute value" behavior. Sliders will snap to the nearest StepValue (mostly only noticeable if you have a very small range or a very large step value) or Tick (if configured to do so). None of the examples step towards the clicked position.

I did check a few sliders on Windows 10 and they had varying behaviors. The Volume Mixer steps in the direction from the slider's current value to the cursor (this can cause it to step towards or over the cursor repeatedly). The volume widget from the system tray (not sure if it has a proper name), behaves like a Windows 11 slider. The Levels slider in the Device Properties of Sound settings behaves like Volume Mixer.

That said, the "Windows 11" / "modernwindows" style in Qt 6.7+ is following the Windows 11 and WinUI 3 guidance, which does not have the "step-towards-click" behavior that Windows 10 does. Qt has merged changes for Qt 6.7.2+ to make left-click set the absolute position of the slider. The change for 6.7.1 is still pending.
https://codereview.qt-project.org/c/qt/qtbase/+/560228
https://codereview.qt-project.org/c/qt/qtbase/+/561096
https://codereview.qt-project.org/c/qt/qtbase/+/561216
qt/qtbase@392c5fa
qt/qtbase@78bf5f7

As far as I know, Qt's Fusion style (what is used outside of Windows and macOS), will still use left-click for "page-step" behavior.

We can either be opinionated about how we want sliders to behave in our application, or we can defer to the OS/style/framework. As far as I can tell, our issue is that we want the context bar's slider (MediaSlider/AbsoluteSlider) to behave a certain way, but do not necessarily want all sliders to behave that way.

Are all of these commits blocking #10625, or is it just the first commit? If it's just the first commit (UI: Move VolumeSlider widget to volume control), we could split that out from the other two, merge that since I think that's uncontroversial, and then discuss the remaining changes separately. The second commit (UI: Rename MediaSlider to AbsoluteSlider) might also be uncontroversial. If help is needed splitting stuff up, I can assist.

On the ProxyStyle changes, the main motivation for removing it here is because it fixes some odd behavior on theme switching, is that correct? Additionally, we always want some sliders (in this case, the context bar media seek bar) to behave a specific way on all platforms in all Qt Styles, so it must be made to do so. Do I understand that correctly?

[Warchamp7]

We can either be opinionated about how we want sliders to behave in our application, or we can defer to the OS/style/framework. As far as I can tell, our issue is that we want the context bar's slider (MediaSlider/AbsoluteSlider) to behave a certain way, but do not necessarily want all sliders to behave that way.

This is correct

Are all of these commits blocking #10625, or is it just the first commit? If it's just the first commit (UI: Move VolumeSlider widget to volume control), we could split that out from the other two, merge that since I think that's uncontroversial, and then discuss the remaining changes separately. The second commit (UI: Rename MediaSlider to AbsoluteSlider) might also be uncontroversial. If help is needed splitting stuff up, I can assist.

Only the first one really

[RytoEX]

Going to make a judgment call and say this is fine. If the change from QProxyStyle to mouseEvent handling causes problems, I can handle the revert of the third commit.

While looking into this, I found QTBUG-125110, which mentions the behavior that this PR seems to describe. The response there so far is:

Palette and font propagation follows different rules when a style sheet is active, see Qt::AA_UseStyleSheetPropagationInWidgetStyles in https://doc.qt.io/qt-6/qt.html#ApplicationAttribute-enum. Generally, mixing style sheets with other styling mechanism will result in hard-to-predict outcomes.