This is currently handled by the QtExtended surface which is an
arbitrary hashmap. This is getting deprecated, and we should do it
properly anyway.
This patch adds it into the existing protocol that sets with a client
surface is decorated or not, as semantically it's very closely related.
Attached unit test
My wayland windows still are decorated
| No Linters Available |
| No Unit Test Coverage |
I'm fine with the change, but when I thought about it, I was wondering whether it would be better to have a dedicated interface. There is at least one other Wayland compositor out there which implements the protocol and I got several requests about upstreaming it. So if at some day it ends up in wayland-protocols I think this request would be too Plasma/KWin specific with a reference to the KColorScheme path. On the other hand one can consider it a point for future as we have to change the code anyway if it ever gets upstreamed.
| src/client/server_decoration.cpp | ||
|---|---|---|
| 291 | nitpick: missing whitespace | |
| src/server/server_decoration_interface.h | ||
| 147 | is it a paletteName or palettePath? IIRC we set complete paths? | |
| src/server/server_decoration_interface.h | ||
|---|---|---|
| 147 | I think we support both (doing a KService lookup if no complete path given), imho "name" would also be consistent with what KConfig uses | |
| src/server/server_decoration_interface.h | ||
|---|---|---|
| 147 | Nothing better than looking into the source: m_colorScheme = QStandardPaths::locate(QStandardPaths::GenericConfigLocation, colorScheme); | |
If it does go into wayland-protocols I imagine it would get renamed?
And even if it did get upstreamed and adopted, Steam (for example) would want to set the palette.
| src/server/server_decoration_interface.h | ||
|---|---|---|
| 147 | Nothing better, and it's what I did, but see the more relevant line above. : m_colorScheme(QFileInfo(colorScheme).isAbsolute()
? colorScheme
: QStandardPaths::locate(QStandardPaths::GenericConfigLocation, colorScheme))Then only go into the branch you looked at if the scheme is "kdeglobals". It's both names and paths. Which is what the XML docs and unit test cover. | |
FYI, I'm deliberately delaying after I heard from Jonas how they might put it in GTK.
Technically they could have a v1 here, and we could have v2 with the added feature set and it would be fine, but I want to see how the discussion plays out before modifying anything.
If the protocol goes upstream I would be in favor of discarding the change as it could mean that also Qt gains support directly. In that case we would need a dedicated protocol for color scheme anyway.