Pet window shows in the taskbar on Linux and closing it removes the pet (#228 side effect)

[pinoybear]

Summary

Since the rebuilt v4.0.0 Linux packages (which include #228), the default pet shows up as a normal window on Linux: it gets a taskbar entry ("electron / OpenPets Default Pet"), appears in Alt+Tab and the pager, and closing it from the taskbar destroys the pet. This happens even with the chat button turned off, which is the v4 default.

Reproduce

1. Install the current OpenPets-4.0.0-linux-x86_64.AppImage (SHA256 7004d8c7fb67be02a6f50d68c56dcd5c39b609e8408c2c73d869bfbfc6c6f49a) on KDE Plasma.
2. Launch it. The pet appears as expected, but there is also a taskbar entry for it.
3. Close that taskbar entry. The pet disappears.

A build from the v4.0.0 tag (before #228) does not have a taskbar entry.

Cause

#228 changed shouldPetWindowBeFocusable() so the pet window is always focusable on X11/XWayland. In Electron on Linux, a window created with focusable: false isn't managed by the window manager at all, and that was the only thing keeping the pet out of the taskbar. The skipTaskbar: true option in pet-window.ts has never had any effect on Linux: Electron 42 documents both skipTaskbar and setSkipTaskbar() as macOS/Windows only.

KWin confirms it. On a build from the v4.0.0 tag the pet window is unmanaged (managed: false). On the rebuilt AppImage it's a normal managed window with skipTaskbar: false and demandsAttention: true. pet-window.ts is identical between the tag and main; wayland-backend.ts is the only non-fix change in between.

Since OpenPets forces --ozone-platform=x11 on Linux by default, I'd expect this to affect most Linux setups regardless of desktop. I've only verified it on KDE Plasma, though.

What I tried

On a dev build from main:

• Calling window.setSkipTaskbar(true) after the window is shown: no effect (as the docs say).
• type: "toolbar" on Linux X11: still in the taskbar. It did clear the attention flag, and chat input still worked.
• A throwaway Electron test with focusable windows of every Linux window type (normal, toolbar, dock, splash, notification): all of them appear in the Plasma taskbar.

So there doesn't seem to be an Electron-options fix. Hiding the pet at the window-manager level does work, though, and chat input still takes typing with it hidden. Staying out of the taskbar and accepting keyboard focus aren't in conflict; Electron just can't request it on Linux.

Possible directions

• Only make the pet focusable while chat or a plugin input is actually in use, e.g. by recreating the window, since KWin won't pick up a runtime setFocusable() change (as fix(desktop): keep X11/XWayland pet windows focusable to fix chat input (#227) #228 found).
• Keep the pet unfocusable on X11 and host the chat input in its own small focusable window.
• Set _NET_WM_STATE_SKIP_TASKBAR on the X11 window before it's first mapped. That needs native code.

At minimum: make closing the pet harmless

Even if the taskbar entry stays for now, closing it shouldn't destroy the pet. Right now the default pet window's close handler in pet-window.ts only saves the pet's position and then lets the close go through, so the window is gone until OpenPets restarts.

The usual Electron pattern would fix that:

• In the pet window's close handler, call event.preventDefault() and hide the pet instead, the same way the tray's "Hide Default Pet" does (hideDefaultPet()).
• Set an "app is quitting" flag in app.on("before-quit") and only cancel the close when it isn't set, so the tray's Quit, logging out and shutting down still close the app normally. OpenPets' own teardown uses destroy(), which doesn't fire close, so it wouldn't be affected.

With that, closing the pet's taskbar entry (or pressing Alt+F4 while the pet has focus) would just hide the pet. Its taskbar entry goes away with it, and "Show Default Pet" in the tray brings it back. It doesn't remove the taskbar entry while the pet is visible, but it turns an easy accident into something harmless.

One thing to decide: hideDefaultPet() also turns off showing the pet at the next launch, so a close would be remembered across restarts. A plain window.hide() would only hide it until OpenPets restarts. I'm not sure which you'd prefer.

Workaround (KDE only)

A KWin window rule restores the old behavior without breaking chat input: System Settings > Window Management > Window Rules > Add New, match window class open-pets-desktop (exact) and window title OpenPets Default Pet (exact), then force "Skip taskbar", "Skip pager", and "Skip switcher" to Yes. The title match matters because Control Center uses the same window class. This doesn't cover extra agent/plugin pets, which have other titles.

Environment

• CachyOS Linux (rolling), kernel 7.2.7-1-cachyos
• KDE Plasma 6.7.5, KWin 6.7.5
• OpenPets v4.0.0 (rebuilt Linux packages), Electron 42.0.0
• Launched with --ozone-platform=x11 (XWayland)

[alvinunreal]

Implementation and VM verification update (not merged or released yet): I fixed both regressions together. Linux X11/XWayland pet carriers remain focusable for chat/plugin inputs; a pre-show X11 watcher observes the actual map transition and requests taskbar/pager exclusion (plus KDE switcher exclusion) from the window manager, because Chromium overwrites pre-map _NET_WM_STATE on first show. A window-manager close now temporarily hides the default pet without clearing its launch preference; tray Show reuses it. Normal Linux launches also select X11 before Electron initializes its display backend, while OPENPETS_ALLOW_WAYLAND=1 retains the native-Wayland opt-out.

Verified on packaged arm64 KDE/X11: skip hints on first show, the pet absent from a captured Alt+Tab switcher, real typing into the pet chat, WM close → “Show Default Pet” tray label → re-show of the same window, and unchanged launch preference. On packaged GNOME/Wayland, an unflagged launch relaunches into XWayland with a real XID and the standard skip hints; the native-Wayland opt-out also works. A GNOME keyring modal prevented a trustworthy GUI-level Alt+Tab/typing pass there, so property checks are not being claimed as compositor UI proof. A mounted arm64 AppImage launched through the same startup path and obtained the skip hints. Desktop checks, docs build, packaging contract, and diff check pass. Changes remain uncommitted and unreleased.

[alvinunreal]

Follow-up to my verification update: the fix is now proposed in PR #234. The review found and we addressed a KDE switcher-hint race, deferred-show tray-label timing, and Linux development-process supervision before opening it. The PR includes the final VM checks and remaining GNOME GUI-test limitation. It has not been merged or released yet.

[alvinunreal]

Additional PR #234 verification: after clearing the GNOME VM dialogs, the visible pet was absent from a captured GNOME Alt+Tab switcher listing Files and Terminal, and typed text appeared in its chat field. The earlier GNOME GUI-test caveat is resolved for this arm64 VM; the PR description has been updated. This is still unmerged and unreleased.

[alvinunreal]

Update: the separate Linux-only rebuild was superseded and removed. The four fixed Linux x86-64 packages now replace the Linux downloads on the main OpenPets v4.0.0 release. The AppImage has SHA-256 4080c06327fc7a4d9fcd5475848db0df6ff43f7bb807955046321b231204e56f; DEB, RPM, tar.gz and the complete SHA256SUMS are on that release. PR #234 is merged. Ubuntu x86-64 CI validated all four packages and the installed DEB passed normal-sandbox X11 startup, pet skip states, and WM-close checks. Because the app version remains 4.0.0, manually reinstall/replace your Linux package; there is no automatic newer-version notification. The v4.0.0 tag still points to its original source archive; release notes identify the merged Linux build commit.

[alvinunreal]

Release update: #234 is merged. The four Linux packages on the existing OpenPets v4.0.0 release were replaced with builds from merged main commit 4d5d0dd393e18cbe983d5cfa1b32b7bf3b2b1ce9; the full SHA256SUMS was updated and macOS/Windows assets were unchanged. The new x86-64 AppImage is SHA-256 4080c06327fc7a4d9fcd5475848db0df6ff43f7bb807955046321b231204e56f. Ubuntu x86-64 CI validated all four package payloads and tested installed-DEB sandboxed X11 startup, pet taskbar/pager states, and WM close. KDE/GNOME arm64 VM GUI checks covered Alt+Tab and typing. Download and manually reinstall/replace the Linux package: the version remains 4.0.0, so no automatic newer-version update will be offered. The separate rebuild release was removed after these replacement assets were verified.

[pinoybear]

Tested the replaced v4.0.0 AppImage (SHA-256 4080c06327fc7a4d9fcd5475848db0df6ff43f7bb807955046321b231204e56f) on Plasma 6.7.5, and your fix works. I removed the KWin rule workaround first, so this is your fix on its own.

• No taskbar entry for the pet, and it's not in Alt+Tab or the pager. KWin reports skip taskbar, pager and switcher all set on the pet window.
• Chat input takes typing.
• Closing the pet through the window manager hides it instead of destroying it. The tray switches to "Show Default Pet", which brings the same window back, and openDefaultPetOnLaunch stays true.
• Control Center still gets its normal taskbar entry.
• Same result after a reboot with autostart. The log shows the MapNotify watcher setting all three atoms (optionalKdeHintsPresent=1), with no warnings or errors.
• Closing the laptop lid minimizes the pet, and it comes back by itself when the lid opens, still out of the taskbar, with the atoms verified again.
• fix(desktop): refresh pet content after wander/move completes #224, fix(desktop): capture webContents.id before Control Center window is destroyed #225 and test(desktop): verify the renderer bundle is actually packaged in app.asar #226 are all still in this build.

One small thing: while the pet is minimized with the lid closed, every show request logs X11 map lifecycle failed after readiness … error="X11 map lifecycle timed out after 1200ms" at ERROR level. Nothing breaks and it recovers as soon as the lid opens, so it's probably just noise, but I figured you'd want to know.

My first soak test got cut short by the Calendar Airmail crash in #235 (fixed in #236), which had nothing to do with this change. Since then I've been running main with #236 on top, and last night I left it overnight with the lid closed, about 8 hours. It logged the whole time with no errors or warnings, and the pet came back fine in the morning, still out of the taskbar.

Environment: CachyOS, kernel 7.2.7-1-cachyos, KDE Plasma 6.7.5 / KWin 6.7.5, --ozone-platform=x11.

Appreciate all the quick replies and turnaround!