feat: add own_window_namespace config setting for wlr-layer-shell

[sniper1720]

Checklist

• I have described the changes
• I have linked to any relevant GitHub issues, if applicable
• Documentation in doc/ has been updated
• All new code is licensed under GPLv3

Description

The changes: a new own_window_namespace config setting for the namespace passed to get_layer_surface(). It defaults to "conky" (unchanged behaviour for every existing config); a user can opt in to another classification, e.g. own_window_namespace = 'desktop' for desktop-widget behaviour. The setting is guarded by BUILD_WAYLAND only.

Why they were necessary: on KDE Plasma (Wayland), KWin derives the window type from the layer-shell namespace via scopeToType(). "conky" is not in its map, so every conky surface is classified WindowType::Normal regardless of the layer it is on. Normal windows are what Workspace::setShowingDesktop() hides, so Show Desktop (Meta+D) hides conky desktop widgets even though they sit on the BACKGROUND layer. The setting also lets dock/normal users decouple classification from the layer, e.g. keep own_window_type = 'normal' on the bottom layer while KWin still treats the surface as a desktop window.

How it affects existing behaviour: nothing changes for existing configs: the namespace stays "conky" unless own_window_namespace is set explicitly. Configs that set own_window_namespace = 'desktop' stay visible during Show Desktop on KDE Plasma, matching the X11 backend.

How it was tested: built and shipped as a patched AppImage (v1.24.3-patched.2); verified interactively on KDE Plasma 6 (Wayland): desktop widgets stay on screen through repeated Meta+D cycles with own_window_namespace = 'desktop'. The X11 backend is untouched.

Closes #2432

[netlify]

✅ Deploy Preview for conkyweb canceled.

Name	Link
🔨 Latest commit	3650c0a
🔍 Latest deploy log	https://app.netlify.com/projects/conkyweb/deploys/6a7e9c4cb5547c000725df7d

[Uri-Tauber]

I can confirm the fix is working.
I had this bug with Conky 1.24.2, when Peek at Desktop would remove all windows include Conky. I compiled this PR and it solve the bug.
Thanks @sniper1720!

If it relevant: I'm using Debian 13 with KDE 6.3.6. Wayland (Obviously).

[sniper1720]

I can confirm the fix is working. I had this bug with Conky 1.24.2, when Peek at Desktop would remove all windows include Conky. I compiled this PR and it solve the bug. Thanks @sniper1720!

If it relevant: I'm using Debian 13 with KDE 6.3.6. Wayland (Obviously).

Thanks for testing and confirming! I hope this PR gets merged soon so I can replace my patched AppImage with the official build for my custom Conky themes.

[Uri-Tauber]

@sniper1720 Your Pure theme looks very good!
Somewhat similar to my own

Great minds think alike. 😄

[rcspam]

@sniper1720 , @brndnmtthws
This also fixes a second, unrelated-looking bug: other windows snap to conky
while you drag them.

KWin's canSnap() (workspace.cpp) already skips desktops and docks as snap
targets. But with the hardcoded "conky" namespace, scopeToType() falls back
to WindowType::Normal, so conky is a regular snap target no matter which
layer it sits on. Dragging any window near it makes the window jump and stick
to conky's edges. No own_window_type value could work around it, since the
namespace was the same for all of them.

With this PR and own_window_type = 'desktop', KWin classifies conky as
WindowType::Desktop and the snapping stops, without touching WindowSnapZone.

One thing I hit while testing further: on KWin the namespace and the layer are
two separate knobs, and deriving one from the other ties them together.

own_window_type = 'desktop' requests the BACKGROUND layer, which KWin maps
to DesktopLayer, the same layer as the plasmashell desktop. Clicking the
desktop raises it above conky and the opaque wallpaper hides it (#2306).
Avoiding that means leaving the desktop type, which also gives up the
namespace this PR grants, so Show Desktop breaks again. On KDE you currently
get one or the other.

Decoupling them is a few lines. In src/output/gui.cc:

#ifdef BUILD_WAYLAND
conky::simple_config_setting<std::string> own_window_namespace(
    "own_window_namespace", PACKAGE_NAME, false);
#endif

and at the get_layer_surface call site the hardcoded "conky" becomes the
setting's value. The default is PACKAGE_NAME, so nothing changes for anyone
who does not set it.

own_window_type then picks the layer, own_window_namespace picks the KWin
window type. Running here with own_window = false (bottom layer, no struts)
plus own_window_namespace = 'dock': Show Desktop keeps conky on screen,
clicking the desktop keeps conky on screen, normal windows still cover it, and
the maximize area is unchanged.

Tested on Plasma/KWin 6.6.5 Wayland, conky 1.24.2 built from source. Happy to
open a follow-up PR with this if you want it.

[sniper1720]

@sniper1720 Your Pure theme looks very good! Somewhat similar to my own

Great minds think alike. 😄

Thank you for the kind words, I appreciate it!

[sniper1720]

@sniper1720 , @brndnmtthws This also fixes a second, unrelated-looking bug: other windows snap to conky while you drag them.

KWin's canSnap() (workspace.cpp) already skips desktops and docks as snap targets. But with the hardcoded "conky" namespace, scopeToType() falls back to WindowType::Normal, so conky is a regular snap target no matter which layer it sits on. Dragging any window near it makes the window jump and stick to conky's edges. No own_window_type value could work around it, since the namespace was the same for all of them.

With this PR and own_window_type = 'desktop', KWin classifies conky as WindowType::Desktop and the snapping stops, without touching WindowSnapZone.

One thing I hit while testing further: on KWin the namespace and the layer are two separate knobs, and deriving one from the other ties them together.

own_window_type = 'desktop' requests the BACKGROUND layer, which KWin maps to DesktopLayer, the same layer as the plasmashell desktop. Clicking the desktop raises it above conky and the opaque wallpaper hides it (#2306). Avoiding that means leaving the desktop type, which also gives up the namespace this PR grants, so Show Desktop breaks again. On KDE you currently get one or the other.

Decoupling them is a few lines. In src/output/gui.cc:

#ifdef BUILD_WAYLAND
conky::simple_config_setting<std::string> own_window_namespace(
    "own_window_namespace", PACKAGE_NAME, false);
#endif

and at the get_layer_surface call site the hardcoded "conky" becomes the setting's value. The default is PACKAGE_NAME, so nothing changes for anyone who does not set it.

own_window_type then picks the layer, own_window_namespace picks the KWin window type. Running here with own_window = false (bottom layer, no struts) plus own_window_namespace = 'dock': Show Desktop keeps conky on screen, clicking the desktop keeps conky on screen, normal windows still cover it, and the maximize area is unchanged.

Tested on Plasma/KWin 6.6.5 Wayland, conky 1.24.2 built from source. Happy to open a follow-up PR with this if you want it.

I'm glad this PR brought out all this potential and even revealed a hidden bug and better concept! Honestly, I didn't catch that issue while testing my Conky themes on KDE Plasma.

The own_window_namespace idea is solid and clean. I checked the documentation and codebase, and it doesn't exist in the official Conky config or source yet: the namespace is hardcoded to "conky" in display-wayland.cc (with no config setting to override it; the only variation is this PR's desktop/conky conditional derived from own_window_type). Since the namespace field is a standard required field in zwlr-layer-shell-v1, exposing it as a config option is definitely the right move.

The coupling problem you hit is real, and I ran into it as well. On KDE, own_window_type = 'desktop' gets the namespace right for Show Desktop, but it also places the surface on the BACKGROUND layer where the wallpaper hides it. Decoupling them with a separate own_window_namespace setting fixes that cleanly.

What I suggest (though I'm open to discussion) is to wait for this PR to land first, and then we can open a follow-up PR adding own_window_namespace, defaulting to "conky" for backward compatibility.

Thanks for the thorough testing and analysis. I'm happy to collaborate on the follow-up if you're up for it!

[netlify]

✅ Deploy Preview for conkyweb canceled.

Name	Link
🔨 Latest commit	b631cf5
🔍 Latest deploy log	https://app.netlify.com/projects/conkyweb/deploys/6a99c917e6efbc0008557f6f

[sniper1720]

I honestly couldn't be more patient after @rcspam's hint and the whole thread, I went and played with the code directly. I changed a few lines and found a recipe that actually works end to end, tested on real hardware.

What I changed

Replaced the hardcoded desktop ? "desktop" : "conky" ternary with a configurable own_window_namespace setting, defaulting from own_window_type so the common cases need no config:

std::string namespace_str = own_window_namespace.get(*state);
if (namespace_str.empty()) {
  switch (own_window_type.get(*state)) {
    case window_type::DESKTOP: namespace_str = "desktop"; break;
    case window_type::DOCK:    namespace_str = "dock";    break;
    case window_type::PANEL:   namespace_str = "panel";   break;
    default:                   namespace_str = PACKAGE_NAME; break;
  }
}

• Setting declared in gui.cc / gui.h alongside own_window_title / own_window_class.
• Docs entry added in config_settings.yaml (own_window_namespace).

What I tested, and with what

Built my fork of conky as a patched AppImage and ran it on KDE Plasma Wayland:

• AppImage build
• Commit: 247e1700 on the fix/wayland-desktop-namespace branch (this PR)

Verified on KWin:

• own_window_type='normal' + own_window_namespace='desktop' → persists through Show Desktop and stays above the wallpaper.
• desktop, dock, panel defaults derive to matching namespaces.

I'd love your feedback and any suggestions on the approach before calling this merge-ready, especially on whether the type-derived default feels right.

[rcspam]

Hi @sniper1720 ,
The setting is exactly what I had in mind, thanks for doing it.

One thing though: I would keep conky as the default. Today every conky uses that namespace. With your default, someone running own_window_type = 'dock' suddenly gets the dock namespace, and KWin starts treating their conky as a dock. Their conky changes behaviour on its own, they did not ask for anything.

Keep conky as the default and nobody is affected. Whoever wants the fix adds one line: own_window_namespace = 'desktop'.

Details, for the record:

• KWin's scopeToType() (layershellv1window.cpp) only knows desktop, dock, critical-notification, notification, tooltip, on-screen-display, dialog, splash and utility. Evormal, so the PANEL case derives a namespace KWinignores.
• The derivation reads own_window_type even when owown_window_type = 'desktop' in an old config, whichX11 ignores in that case, would now pick up the desktop namespace on Wayland.
• The setting is declared under #if defined(OWN_WIN) but only does anything on Wayland, so an X11-onlybuild accepts and ignores it. BUILD_WAYLAND alone would be enough.
• The doc entry says KWin derives the window class window type.

I have only read the diff, I have not rebuilt your

[sniper1720]

Hi @sniper1720 , The setting is exactly what I had in mind, thanks for doing it.

One thing though: I would keep conky as the default. Today every conky uses that namespace. With your default, someone running own_window_type = 'dock' suddenly gets the dock namespace, and KWin starts treating their conky as a dock. Their conky changes behaviour on its own, they did not ask for anything.

Keep conky as the default and nobody is affected. Whoever wants the fix adds one line: own_window_namespace = 'desktop'.

Details, for the record:

* KWin's scopeToType() (layershellv1window.cpp) only knows desktop, dock, critical-notification, notification, tooltip, on-screen-display, dialog, splash and utility. Evormal, so the PANEL case derives a namespace KWinignores.

* The derivation reads own_window_type even when owown_window_type = 'desktop' in an old config, whichX11 ignores in that case, would now pick up the desktop namespace on Wayland.

* The setting is declared under #if defined(OWN_WIN) but only does anything on Wayland, so an X11-onlybuild accepts and ignores it. BUILD_WAYLAND alone would be enough.

* The doc entry says KWin derives the window class  window type.

I have only read the diff, I have not rebuilt your

Thanks for the review! Keeping "conky" as the default was spot on, so I reworked the branch:

• Removed type-derived default: Namespace stays "conky" unless explicitly set (e.g., own_window_namespace = 'desktop'), keeping existing configs unaffected.
• Wayland-only: Guarded the setting with BUILD_WAYLAND.
• Docs updated: Removed panel after checking KWin's scopeToType() (only 9 recognized namespaces, everything else falls back to Normal).

Validated on KDE Plasma 6 Wayland via a patched AppImage with our themes setting the namespace explicitly.

Would love your take on the updated commit. Anything you'd change?

[rcspam]

@sniper1720

Looks good to me now, nothing blocking.

One data point worth putting in the docs: with own_window_namespace = 'dock', conky jumped in front of everything while switching virtual desktops, then dropped back. That is KWin's slide effect, shouldElevate() returns isDock() (src/plugins/slide/slide.cpp), so docks get elevated for the duration of the animation. Switching to 'desktop' fixed it here, conky stays in the background throughout. Another reason your doc entry is right to recommend it.

Two nits:

• In gui.h the extern sits inside the #if defined(OWN_WINDOW) || defined(BUILD_WAYLAND) block, while the definition in gui.cc is now under BUILD_WAYLAND alone. Harmless, but the guards should match.
• The extern has no doc comment, unlike own_window_class and own_window_type right above it.

Also, your namespace list is right as is. KWin has a typo in that table, the key reads "crititical-notification" from 6.4 through 6.7 and is fixed only on master, so leaving it out is the accurate call.

[sniper1720]

@sniper1720

Looks good to me now, nothing blocking.

One data point worth putting in the docs: with own_window_namespace = 'dock', conky jumped in front of everything while switching virtual desktops, then dropped back. That is KWin's slide effect, shouldElevate() returns isDock() (src/plugins/slide/slide.cpp), so docks get elevated for the duration of the animation. Switching to 'desktop' fixed it here, conky stays in the background throughout. Another reason your doc entry is right to recommend it.

Two nits:

* In gui.h the extern sits inside the #if defined(OWN_WINDOW) || defined(BUILD_WAYLAND) block, while the definition in gui.cc is now under BUILD_WAYLAND alone. Harmless, but the guards should match.

* The extern has no doc comment, unlike own_window_class and own_window_type right above it.

Also, your namespace list is right as is. KWin has a typo in that table, the key reads "crititical-notification" from 6.4 through 6.7 and is fixed only on master, so leaving it out is the accurate call.

Applied all three:

• Guard: The extern in gui.h is now guarded under #ifdef BUILD_WAYLAND, matching the definition in gui.cc. Kept it Wayland-only since own_window_namespace has no X11 parallel (X11 window type comes from own_window_type; the namespace is only passed to zwlr_layer_shell_v1_get_layer_surface).
• Doc comment: Added a /// comment above the extern in the same style as own_window_title/own_window_class, noting KWin classifies from the namespace (referencing scopeToType() in layershellv1window.cpp) and that unlisted names like the default "conky" fall back to a normal window.
• Doc entry: Extended config_settings.yaml to include your slide data point: on KDE, dock is elevated by shouldElevate() while switching virtual desktops, so desktop keeps Conky in the background throughout.

@rcspam Thanks again for the review and the working data point on the slide behavior!

[rcspam]

Confirmed on my side, all three points are addressed. Nothing blocking.

Two leftovers, both cosmetic:

• The own_window_namespace entry in config_settings.yaml sits after
  own_window_type, but the list is alphabetical (own_window, _class,
  _colour, _hints, _title, _type). It belongs between own_window_hints
  and own_window_title.
• The default is spelled twice: "" in gui.cc, then the
  if (namespace_str.empty()) fallback to PACKAGE_NAME in
  display-wayland.cc, while the doc says default: 'conky'. Declaring
  the setting as ("own_window_namespace", PACKAGE_NAME, false) drops the
  if. The only behaviour change is that an explicit
  own_window_namespace = '' would then reach the compositor as an empty
  scope instead of falling back to "conky", which is arguably what the
  user asked for anyway.

Also double-checked scopeToType() on kwin master: the .toLower() your
doc entry mentions is there, and the namespace list matches.

[sniper1720]

Confirmed on my side, all three points are addressed. Nothing blocking.

Two leftovers, both cosmetic:

* The `own_window_namespace` entry in `config_settings.yaml` sits after
  `own_window_type`, but the list is alphabetical (own_window, _class,
  _colour, _hints, _title, _type). It belongs between `own_window_hints`
  and `own_window_title`.

* The default is spelled twice: `""` in `gui.cc`, then the
  `if (namespace_str.empty())` fallback to `PACKAGE_NAME` in
  `display-wayland.cc`, while the doc says `default: 'conky'`. Declaring
  the setting as `("own_window_namespace", PACKAGE_NAME, false)` drops the
  `if`. The only behaviour change is that an explicit
  `own_window_namespace = ''` would then reach the compositor as an empty
  scope instead of falling back to "conky", which is arguably what the
  user asked for anyway.

Also double-checked scopeToType() on kwin master: the .toLower() your doc entry mentions is there, and the namespace list matches.

Applied both, confirmed.

• Moved own_window_namespace to sit alphabetically between own_window_hints and own_window_title, and consolidated the default to a single ("own_window_namespace", PACKAGE_NAME, false) in gui.cc, dropping the empty-string fallback in display-wayland.cc. The one behavior change matches your note: an explicit '' now reaches the compositor empty; no theme sets it, so nothing changes in practice.
• Thanks for confirming scopeToType() on master; the doc entry matches.

This also confirms the whole feature is scoped correctly: it only affects compositors with zwlr_layer_shell_v1 (KWin and the wlroots family), and the conky default keeps it behavior-neutral everywhere else.