Pet can't be dragged near the top of the screen on KDE since #228

[pinoybear]

Since #228 made the pet window focusable, I can't drag the pet anywhere near the top of the screen on KDE Plasma. It stops a few hundred pixels below the top, like there's an invisible wall. Same on a second laptop with a fresh install of the AUR package, so it isn't specific to my setup.

The pet window is 340x420 and the pet sits in the bottom part of it, with the space above kept free for bubbles. Before #228 the window wasn't managed by KWin, so you could drag it partly above the screen edge (the empty bubble area just went off-screen) and the pet could sit right under the panel. Now KWin manages the window and won't let a move requested by the app put it over the panel or above the screen, so the top of the window stops at the panel. On my setup (32 px top panel, pet scale 0.5) that leaves the pet unable to get above roughly y=292.

It isn't the drag code: the drag handler calls setBounds with no clamp, and moving the window through KWin itself (kdotool windowmove to y=0) works fine. It's KWin constraining app-requested moves on a managed window.

I checked with a small standalone Electron script: two frameless windows, one focusable: false (like the pet before #228) and one focusable: true (like now), both moved with setBounds:

Window	Requested	Actual
focusable: false	y=0	y=0
focusable: true	y=0	y=32
focusable: false	y=-150	y=-150
focusable: true	y=-150	y=32

Wandering was already kept inside the work area by clampToVisibleWorkArea (with multi-monitor roaming off, the default), so this only affects dragging.

Reproduce

1. KDE Plasma (Wayland session, OpenPets on XWayland with the default --ozone-platform=x11).
2. Drag the pet toward the top of the screen.
3. It stops with the invisible top of its window at the top of the work area (the bottom of a top panel, or the screen edge), leaving the pet a few hundred pixels lower.

I'm not sure what the best fix is. A few options I thought of: only make the window focusable while the chat input is open, a window type or hint that KWin doesn't constrain (keeping the #234 skip atoms), or clamping to the visible pet instead of the whole window. Happy to test anything.

Environment: CachyOS, kernel 7.2.7-1-cachyos, KDE Plasma 6.7.5 / KWin 6.7.5 (Wayland session). Laptop 1: main f24f934 (4.0.0 + #236), 100% scaling, 32 px top panel. Laptop 2: fresh openpets-bin 4.0.0-1 from the AUR, 115% scaling.

[pinoybear]

I dug into it more and here's what I see happening:

• The clamp isn't unique to how OpenPets does the drag today. Real drags on the actual pet window (tested on 4.0.1) show it every time, straight from OpenPets' own log:

drag start windowId=1 point={"screenX":"1710","screenY":"900"} startBounds={"x":"1548","y":"535","width":"340","height":"420"}
drag end windowId=1 position={"x":"1916","y":"32"}
drag start windowId=1 point={"screenX":"2061","screenY":"380"} startBounds={"x":"1916","y":"32","width":"340","height":"420"}
drag end windowId=1 position={"x":"2220","y":"32"}
drag start windowId=1 point={"screenX":"2276","screenY":"379"} startBounds={"x":"2104","y":"32","width":"340","height":"420"}
drag end windowId=1 position={"x":"1631","y":"32"}

A standalone script reproduces the mechanism directly: two frameless windows, one focusable: false and one focusable: true, both calling setBounds() to the same off-panel position:

nonFocusable: requested y=-150 -> actual y=-150
focusable: requested y=-150 -> actual y=32

• I initially thought the fix might be to hand the interactive move off to the window manager via the EWMH _NET_WM_MOVERESIZE protocol at drag start, instead of the app tracking pointer movement and calling setBounds() itself — that's the standard way apps implement custom-drag-region windows on X11. I tried it (sent the client message, drove a real synthetic drag with xdotool, watched the window itself move) and it clamps to the exact same y=32. So that's ruled out, not a fix.
• What does escape the clamp: moving the window directly through KWin's own scripting/D-Bus API (workspace...move-style), outside of any interactive drag session — that lands wherever asked, no clamp, confirmed at y=-150. So the real distinction isn't "who requests the move," it's "a live interactive move/drag session" (clamped, whichever of the app or the WM is driving it) versus "an instantaneous scripted placement with no drag in progress" (not clamped). Not something an app can normally invoke for its own live drag without shipping or requiring a KWin script, so more a diagnostic clue than a usable fix path.

No working fix from this, but hopefully useful to rule out that direction and narrow down where to look next. Happy to help test anything.

Environment:

• CachyOS, kernel 7.2.8-1-cachyos
• KDE Plasma 6.7.5 / KWin 6.7.5
• OpenPets 4.0.1
• --ozone-platform=x11