Kando fails to start on KDE Plasma Wayland: unhandled DBusError: An app id is required

[Branrir]

Short Summary

On KDE Plasma Wayland, a rejected global-shortcuts portal CreateSession call is never propagated, causing an unhandled promise rejection that hangs initialization so the window never opens.

Steps to Reproduce the Issue

1. Build/run Kando on a KDE Plasma Wayland session (xdg-desktop-portal-kde present).
2. Launch the packaged app (e.g. out/Kando-linux-x64/...).
3. During startup the KDE Wayland backend calls globalShortcuts.isAvailable(), which triggers the global-shortcuts portal CreateSession.
4. xdg-desktop-portal-kde rejects the call with DBusError: An app id is required.
5. The window never appears; the following is logged:

(node:13350) UnhandledPromiseRejectionWarning: DBusError: An app id is required
    at .../resources/app/.webpack/main/index.js:2:367127
    ...
(node:13350) UnhandledPromiseRejectionWarning: Unhandled promise rejection. ...

Kando Version

3.0.0-alpha.0 (built from source, main)

Installation Method

Directly from the main branch

Desktop Environment

KDE on Wayland

Environment Version

CachyOS · Linux 7.0.12-1-cachyos · KDE Plasma Wayland session

Additional Information

Proposed fix:

• makeRequest propagates the underlying D-Bus call's rejection (and removes its message listener) instead of waiting indefinitely.
• The portal callbacks in global-shortcuts.ts and remote-desktop.ts return their D-Bus call promises so rejections reach makeRequest.

With this change, a failed portal request rejects cleanly, connectImpl's catch runs, and the KDE backend falls back to its KWin-scripting method as intended — the app starts normally.

Verified with npm run tscheck, eslint, and prettier passing, and Kando launching on KDE Plasma Wayland.

PR #1413 is created

[Schneegans]

Hi there! Thanks a lot for looking into this. Yet I wonder why that rejection is done in the first place. After doing some research, I think the reason is that we have to call this register API: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.host.portal.Registry.html

Would you mind looking into that? I'm not sure since when it is mandatory for unsandboxed apps to call this (for me, it still works without) but maybe you could eliminate the root cause using this!

I think in portals/registry.ts you could create a mini portal which offers just the register method. Each backend using portals should all this in their init-method (if the portal is available). As app ID we should use the desktopName from the package.json file (import { desktopName } from './../../../../package.json';).

Do you think you could add this?

[Branrir]

Hi there! Thanks a lot for looking into this. Yet I wonder why that rejection is done in the first place. After doing some research, I think the reason is that we have to call this register API: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.host.portal.Registry.html

Would you mind looking into that? I'm not sure since when it is mandatory for unsandboxed apps to call this (for me, it still works without) but maybe you could eliminate the root cause using this!

I think in portals/registry.ts you could create a mini portal which offers just the register method. Each backend using portals should all this in their init-method (if the portal is available). As app ID we should use the desktopName from the package.json file (import { desktopName } from './../../../../package.json';).

Do you think you could add this?

I can look into it, but will for sure take some time. Will update you when i get some results. Thanks for the pointers.