SUMMARY Wayland and X11 behave inconsistently when using dockapps like Gkrellm. On X11: if I launch Gkrellm, set it as a dockapp, and then place it on one screen edge, then the working area of the screen is adjusted so that maximised windows don't cover it. Also, it doesn't appear on the task bar. On Wayland: if I do exactly the same thing on Wayland, maximised windows end up the full size of the window so that one edge of it is obscured by the Gkrellm window. It also appears on the task bar as a generic X window. It's completely reproduceable on multiple machines so I think it's a core window manager bug in how struts are handled. SOFTWARE/OS VERSIONS KDE Plasma 6.5.3 KDE Frameworks 6.20.0 QT 6.9.2 Kernel: Linux 6.16.12-amd64 Processor: Core Ultra 7 Memory: 64GB Graphics: Intel Output of xprop of Gkrellm (it's the same result on both X11 and Wayland): ``` _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP _NET_WM_DESKTOP(CARDINAL) = 0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 67, 0, 0, 0, 0, 0, 1158, 0, 0, 0, 0 _NET_WM_STRUT(CARDINAL) = 0, 67, 0, 0 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x3400017 window id # of group leader: 0x3400001 _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0 _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 2754429 _NET_WM_ICON(CARDINAL) = Icon (16 x 16): ▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓ ▓▓▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒░░░░░░░░░░▒▒░░░░▒▒▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒░░ ░░▒▒▒▒░░░░░░▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒▒▒░░ ▒▒▓▓░░░░░░░░▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒░░▓▓ ▓▓░░░░░░░░░░▒▒▒▒▒▒▒▒ ▓▓▒▒░░░░▒▒ ▒▒░░░░░░ ░░▒▒▒▒▒▒▒▒ ▓▓▒▒░░▓▓▒▒ ▒▒░░░░░░ ░░▒▒▒▒▒▒▒▒ ▓▓░░▓▓▒▒▒▒ ▒▒░░░░░░░░▒▒▒▒▒▒▒▒▒▒ ▓▓░░▓▓▒▒▒▒ ▒▒░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒▒▒▒▒ ▒▒░░░░░░░░▒▒▒▒▒▒▒▒▒▒ ▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▓▓▓▓▓▓▓▓▓▓▒▒▓▓▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓ _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 54525957 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x3400004 WM_CLIENT_LEADER(WINDOW): window id # 0x3400001 _NET_WM_PID(CARDINAL) = 35909 WM_LOCALE_NAME(STRING) = "en_US.UTF-8" WM_CLIENT_MACHINE(STRING) = "dtrg02" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 67 by 1158 program specified maximum size: 67 by 1158 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "gkrellm", "Gkrellm" WM_ICON_NAME(STRING) = "gkrellm" _NET_WM_ICON_NAME(UTF8_STRING) = "gkrellm" WM_NAME(STRING) = "gkrellm" _NET_WM_NAME(UTF8_STRING) = "gkrellm" ```
We do not support desktop components running as X11 apps
Are you sure? This isn't really a desktop component, just a normal application which integrates into the desktop. Doesn't this prevent a whole slew of perfectly useful applications from running on Wayland?
Yes. X11 struts are not supported. > Doesn't this prevent a whole slew of perfectly useful applications from running on Wayland? No, it's an incredibly niche thing that just caused problems. If an application wants to support operating as a panel, that is allowed through the layer shell protocol.