Hi, What's the best way to detect >at the level of a style's menu rendering methods< whether or not the application or even the widget in question uses a different palette than the current desktop colour palette? I have a draft method which works fine where I want it to but tends to trigger in unexpected cases (without visible effect; see below) so I'd appreciate suggestions how to detect this kind of situation more reliably.
Context (yes, under Linux/X11 :)) : I think this is what is required to let KWin5 draw its window context appropriately for windows that use a different colour palette (and for which KWin5 now adapts the decoration palette; that decoration is of course drawn by KWin, not the app). I haven't yet found how Oxygen and Breeze handle this, maybe overlooking it, or maybe because they don't do anything to modify the palette for rendering menus. This new KWin5 feature does pose a bit of a problem for QtCurve: it allows the user control over certain element colours but also how the desktop palette is modified to render certain other elements (including menus). It uses a mix of precalculated colour tables and runtime switches to determine which colourtable is to be used where. This makes it almost impossible to factor in support for menus with a different palette without completely rewriting the code or increasing its complexity even further. Fortunately it seems there are just 2 locations where a special-case rule is required: the methods that draw the menu backdrop and the method that draws the menu items. I did come up with a first fix/workaround: https://phabricator.kde.org/D5178#b53f2bc6 (line 2900) and https://phabricator.kde.org/D5178#78c8fa59 (line 1270). This works well enough when restricted to KWin5 as it is now. When I remove the application restriction the test triggers also when the desktop palette is being used (except that in that case I see no effect of using the local colour table!). Thanks, René
