Strange Window Move Behavior

[ShayBox]

I noticed that if you grab the window with kwin Window Move vs normally with the taskbar, the window will go blank and won't properly maximize at the top of the screen like normal.

YouTube Video

[ShayBox]

I'm not able to replicate this using Firefox or Dolphin, it may only be Xwayland or Proton/Wine windows.

[luisbocanegra]

I'm not able to replicate this using Firefox or Dolphin, it may only be Xwayland or Proton/Wine windows.

Most likely. Didn't face this with any or my apps through my testing.

Please share the output of kinfo

Enable logging in the Widget settings > Troubleshoot tab then run journalctl -f while you drag this window and share the output, maybe there's some error message

[ShayBox]

$ kinfo
Operating System: CachyOS Linux 
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.6-2-cachyos-lto (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen Threadripper 1950X 16-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: Mesa Intel® Arc

$ prime-run kinfo
Operating System: CachyOS Linux 
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.6-2-cachyos-lto (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen Threadripper 1950X 16-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2

# journalctl -f
Apr 19 01:40:15 Workstation plasmashell[2106]: qml: PPSE: Drag start: QPointF(509, 7)
Apr 19 01:40:16 Workstation plasmashell[2106]: qml: PPSE: Drag end: QPointF(529, 17)
Apr 19 01:40:16 Workstation plasmashell[2106]: qml: PPSE: Drag direction right
Apr 19 01:40:16 Workstation plasmashell[2106]: qml: PPSE: Drag right detected
Apr 19 01:40:16 Workstation plasmashell[2106]: qml: PPSE: RUNNING_ACTION: kwin,Window Move
Apr 19 01:40:16 Workstation plasmashell[2106]: qml: PPSE: RUNNING_SHORTCUT: sh '/home/shaybox/.local/share/plasma/plasmoids/luisbocanegra.panelspacer.extended/contents/ui/tools/run_kwin_script.sh' 'focusTopWindow' '/home/shaybox/.local/share/plasma/plasmoids/luisbocanegra.panelspacer.extended/contents/ui/tools/focusTopWindow.js';qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut "Window Move"
Apr 19 01:40:16 Workstation kwin_wayland[1615]: js: PPSE: PPSE: Focusing top window...
Apr 19 01:40:16 Workstation kwin_wayland[1615]: js: PPSE: active screen: DP-4 current: DP-4
Apr 19 01:40:16 Workstation kwin_wayland[1615]: js: PPSE: Top: VRCX 2024.03.23|vrcx.exe|vrcx.exe|9|DP-4

[ShayBox]

It says drag right even though I did down, is that because the bar is actually rotated?

[luisbocanegra]

It says drag right even though I did down, is that because the bar is actually rotated?

That's weird, according to the points you moved on x (509>529) more than y (7>17).

I suspected was caused by the window buttons widget growing/shrinking, and was right, you just found another issue I wasn't able to catch! (I have it set to show on active window) 🙂

[ShayBox]

I have a few extensions that resize such as Window Title, Global Menu, and Window Buttons

[luisbocanegra]

I have a few extensions that resize such as Window Title, Global Menu, and Window Buttons

Thanks for the observation, opened a new issue for that one.

[ShayBox]

I noticed if you drag the window to the other monitor but not to the top bar to maximize it, it stays maximized. I think if you un-maximize then grab, it'll fix the behavior.

[luisbocanegra]

Is any specific program or it happens with all of them? For me, windows always return to the un-maximized status, only instances of this not happening was when, for some reason, a un-maximized window either was already big enough to fill the screen or a bug of some sort causing the maximized size to become the un-maximized size.

[ShayBox]

Minecraft, every Proton/Wine game/program, it could be XWayland.
I don't think it's an issue with the panel spacer widget, I can replicate it using the default kwin grab key bind, but it's more noticeable with the bar because the behavior isn't as you would expect/matching for all programs.

[luisbocanegra]

I see, the only XWayland program I use is vscode and it doesn't have that problem. I suspect this is something exclusive to games forcing maximized state or a fixed window size perhaps?

[ShayBox]

My VSCode doesn't use XWayland so I can't confirm that, but mine doesn't have that issue either. It could just be games, but the same programs do un-maximize when grabbed from the title bar, just not with kwin grab.

[luisbocanegra]

Huh? Just found out dragging window is broken on X11 session 😭

Was trying to reproduce the maximized thing and to detect the input device for wheel events (so there can be different thresholds for touchpad and mouse) for #30, but the device was always touchpad even when using mouse wheel. So I decided to try with X11 and the device type does change there (probably Qt6 bug).

But the window drag just gets stuck somehow, it's super weird because if I press a key the window teleports to the new cursor position then stays there, also the mouse buttons stop working until I press Esc which returns everything to normal.

I suspect either X11 doesn't like the Switch from MouseArea to Handlers or I overlooked something, because running the raw command works just fine:

sh '/home/luis/.local/share/plasma/plasmoids/luisbocanegra.panelspacer.extended/contents/ui/tools/run_kwin_script.sh' 'focusTopWindow' '/home/luis/.local/share/plasma/plasmoids/luisbocanegra.panelspacer.extended/contents/ui/tools/focusTopWindow.js' true;qdbus6 org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut "Window Move"

[luisbocanegra]

So dragging still works reliably if the mouse is released immediately after leaving the panel (kinda like the previous behavior where clicking dropped the window), I guess adding a note about that is fine? Since nobody reported this most people must be using Wayland anyway...