-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange Window Move Behavior #22
Comments
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 Enable logging in the Widget settings > Troubleshoot tab then run |
|
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) 🙂 |
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. |
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. |
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. |
Minecraft, every Proton/Wine game/program, it could be XWayland. |
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? |
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. |
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 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:
|
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... |
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
The text was updated successfully, but these errors were encountered: