obsproject
UI: Reduce settings dialog default height
Description
Reduce the size of the settings window if greater than the main window.
Motivation and Context
This change should avoid this to happen again on 720p:
OK, Cancel and Apply are not accessible without having to resize the window.
How Has This Been Tested?
- Set manually the main window size at something 720p-like.
- Open the settings window.
- The settings window is smaller in height than the main window.
Types of changes
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
It annoys me that Qt in this case is ignoring the monitor's height and treating the default height more like a minimum height. This should be automatic - "if default window size doesn't fit, resize to be smaller, otherwise stay default". Maybe there's a way for us to force it? Maybe we're setting some default heights of internal widgets somewhere causing it to stretch to its default regardless?
Made the fix in code rather than in UI file.
Edit: If the settings window is bigger than the main window in height, it will be reduce to the main window size less 20.
I wonder if we could use QScreen::availableGeometry to determine the safest maximum size for a window on the current display. Might provide a slightly better experience than basing it on the height of the main window. However, will need to be tested on Wayland.
On one hand, basing this off the size of the main window feels janky.
On the other hand, if someone has made the main window that small despite having more screen real estate, it's not the worst thing to respect that decision in the settings window too.
I think it would be better to use the screen dimensions instead of the main window.
On the other hand, if someone has made the main window that small despite having more screen real estate, it's not the worst thing to respect that decision in the settings window too.
If the asked height is too small for the windows, it will normally not respect the asked size change.
I think it would be better to use the screen dimensions instead of the main window.
We can't because of the Windows 10/11 taskbar which is the main cause of this PR.
On the other hand, if someone has made the main window that small despite having more screen real estate, it's not the worst thing to respect that decision in the settings window too.
If the asked height is too small for the windows, it will normally not respect the asked size change.
I think it would be better to use the screen dimensions instead of the main window.
We can't because of the Windows 10/11 taskbar which is the main cause of this PR.
You can just use 85/90% of the screen dimensions to account for the taskbar's minimum size, which should be sufficient in the vast majority of cases, if not all default cases.
@RytoEX While not perfect this seems reasonable to me? Got any objections to having this merged?
Off-thread review yielded that the constructor is too early for this to occur, as the widget does not yet have its screen updated. Overloading showEvent and handling this there is late enough for the widget's screen to be correct. @Warchamp7 is driving this.
Rebased. Will clean up commits and implement some changes from off-thread review.