Bug 424464 - Context menus of desktop and panel don't follow the color of plasma style
Summary: Context menus of desktop and panel don't follow the color of plasma style
Status: CONFIRMED
Alias: None
Product: libplasma
Classification: Frameworks and Libraries
Component: libplasma (show other bugs)
Version: 5.245.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-20 13:33 UTC by Patrick Silva
Modified: 2023-11-16 23:33 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2020-07-20 13:33:21 UTC
STEPS TO REPRODUCE
1. set global theme to Breeze
2. set plasma style to Breeze Dark
3. right-click on desktop or panel

OBSERVED RESULT
context menu has light color

EXPECTED RESULT
context menu should have dark color

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.19.3
KDE Frameworks Version: 5.72.0
Qt Version: 5.15.0
Comment 1 David Edmundson 2020-07-20 16:10:54 UTC
This was deliberate at the time.

Whether it's a good idea remains an open discussion.
Comment 2 Nate Graham 2020-07-21 15:40:39 UTC
Do you know the history of why this was done deliberately? I agree with Patrick, it feels like a bug.
Comment 3 Christoph Feck 2020-07-21 22:33:44 UTC
I prefer dialogs and menus to be light, and panel to be dark. One reason for me is that black-on-light is easier to read, but panel background should be dark because it touches the screen edge.
Comment 4 David Edmundson 2020-07-21 22:43:16 UTC
>Do you know the history of why this was done deliberately? I agree with Patrick, it feels like a bug.

This is partly guessing, but:

* With xembed (and some SNI usage) system tray icons would be drawing the context menu themeselves. A mix would look weird. (technically valid today, but less so)

* Early Plasma themes were quite gaudy and therefore usage had to be constrained to a more limited usecase (not so much the case today)

* We have a few occasions where QMenu's are created inside libPlasma code. Porting this to be in a UI agnostic form would involve an API break (valid, still).