Bug 456264

Summary: Extra frame behind docks that doesn't respect application style nor is overridable
Product: [Plasma] Breeze Reporter: Georges Stavracas <georges.stavracas>
Component: QStyleAssignee: Plasma Bugs List <plasma-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: matt, nate, noahadvs, RytoEX, uhhadd
Priority: NOR    
Version First Reported In: 5.25.2   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: White frame around docks in OBS Studio

Description Georges Stavracas 2022-07-02 23:38:58 UTC 
Created attachment 150348 [details]
White frame around docks in OBS Studio

The Breeze kstyle forcefully hardcodes drawing a frame on dock widgets [1]. This is a problem for OBS Studio because it clashes with the custom style that it applies on the widgetry. No matter how much we style docks, on the presence of the Breeze style, there is an omnipresent frame rendered disconsidering the application style.

This problem is more pronounced on GNOME environments because, there, this omnipresent frame is rendered in white on top of OBS Studio's dark style. 

STEPS TO REPRODUCE
1. Install OBS Studio, preferrably through Flatpak
2. Open it on GNOME (I think this is also reproducible on KDE too)
3. Notice the unwanted border

OBSERVED RESULT

See the attached screenshot.

EXPECTED RESULT

No extra frames (or, at least, it respects the application style).

SOFTWARE/OS VERSIONS
Linux: Arch (GNOME)
Qt Version: 5.15

ADDITIONAL INFORMATION

[1] https://github.com/KDE/breeze/blob/4222e8e83ae870ffb1ccc3c02775681322f62b88/kstyle/breezestyle.cpp#L1555
Comment 1 Janet Blackquill 2022-07-03 01:43:46 UTC 
That is kinda intentional, to ensure that interactive docks have clearly defined bounds of interaction. We may be able to consider making it possible to hide based on widget flags, but not if that would cause interactive docks in lots of apps to lose their defined borders.

Also, if you're doing this much custom styling, I'd recommend committing to avoiding the style entirely, or doing a better job of respecting it, rather than an in-between, which will always be somewhat buggy and ugly.
Comment 2 Georges Stavracas 2022-07-03 04:07:52 UTC 
(In reply to Jan Blackquill from comment #1)

> Also, if you're doing this much custom styling, I'd recommend committing to
> avoiding the style entirely

How would you suggest doing that? Currently OBS Studio sets the palette, style, and stylesheet [1] manually, but my search-fu wasn't able to find other relevant ways to change the style of the application. Happy to try any suggestions.

[1] https://github.com/obsproject/obs-studio/blob/3ea8dbb3926ca144a629fd70d5388c3db2e5ba2a/UI/obs-app.cpp#L1121-L1124
Comment 3 Nate Graham 2022-07-05 17:32:18 UTC 
FWIW using Qt stylesheets is heavily discouraged as it will produce exactly these kinds of results. See https://www.kdab.com/say-no-to-qt-style-sheets.

It's recommended that the app inherit the system's default QStyle (whatever it is) rather than trying to override parts of it with a Qt stylesheet. If the app developers reeeeeeeeeally want or need to use a custom style for branding purposes, the correct way is to write a custom QStyle and force the app to use it, completely ignoring the system's default QStyle. But layering a Qt stylesheet on top of a QStyle is unfortunately a recipe for sadness and bugs.