-
-
Notifications
You must be signed in to change notification settings - Fork 94
[Bug]: Unable to move window to a different screen #218
Comments
I'm also having this issue. Specifically I have been using the "Window to Next Screen" shortcut to move windows between monitors. While sometimes the shortcut works, most of the time it doesn't. What usually happens is the window zooms in for a second, and an animation sometime plays showing the winow moving to a different monitor, however the window then moves back to the place it was. |
same issue here disabling bismuth fixes it |
Same issue here intermittently, this has been an issue since Krohnkite for me that comes and goes, and seems difficult to pin down. Chrome windows for example tend to move correctly 99% of the time, but Konsole windows fail to move most of the time on latest/2.2.0. In addition, I have a 2560x1440 primary monitor, and a portrait rotated 1440x2560 secondary. Moving from primary to secondary usually works, but it's more difficult to move from secondary to primary, especially if the secondary screen's window is the only window and thus is taller than the primary screen. Given that, and since Konsole is restricted to certain sizes based on the terminal, I suspect this is something to do with a window being "moved" by KWin, and then failing or stalling due to sizing issues not being immediately resolved by bismuth for the new layout. When using floating windows, there is no issue. So my workaround for now is to hit float window, move to next screen, then float window again. |
Same issue here, and also meta+drag and drop won't work, so in monocle layout to move a window to a different screen I have to disable, move and re-enable. Doable but tedious. |
Since the |
This would mean to overwrite default "change window screen" shortcut on kwin, and I have noticed that not all apps have this behavior. Thanks for this awesome project! |
Yeah, I've also noticed that it's very app-dependent and must depend on either framework, or some constraint on window sizing that's being applied by the app. Though even apps only "like" to work, they don't "always" work, unless floated. Haven't been able to pin down the common thread of what works and what doesn't yet.
I've seen kwin scripts add new "replacement" keyboard shortcuts that duplicate the OS built in ones to be able to do both the native kwin action, and insert the kwin script's behaviour when needed. You then end up with a very messy shortcuts panel full of redundant options, of course. It seems like using |
Thanks for your comment. Now I can use the workaround. I tested it and it seems to do the job, at least for now. Previously i had to use Meta + Mouse-drag to move specific windows between screens. |
I have the same problem. Some programs are easily moved using the keyboard shortcuts of KWin, some windows can be moved only in some cases (for example primary to secondary screen, but not secondary to primary), others - never. Moving programs between screens with keyboard shortcut without issues:
Moving programs between screens with keyboard shortcut, not working:
|
Same for me, but firefox (same engine with librefox) just tries to maximize and doesn't move window to another screen |
For me, Dolphin moves fine. But Visual Studio Code doesn't |
KDE without separate tags for each screen, not even virtual desktops only on primary option and bismuth refuses to move window. I came back to stop debugging my own WM config now I have to replace kwin with window manager again :| |
An interesting example: qutebrowser in a normal window won't move with Kwin's keyboard shortcut... but a private window will. That might help narrow down what's causing the issue. |
In there I posted the reason for the bug and how to go around it. |
Hi DashieTM, could you please detail the steps for the workaround? I wasn't able to understand the instructions you left. Thanks! |
Okay, I should have been more clear, so I try again. When you start a program you have a list of rules that kde applies, these rules can either be found in system settings -> window rules. Then you would have to make sure that both vertical and horizontal maximazation are turned off using the forced setting. The second part is making sure that the window is a "normal-window" and not a "dialog-window". All these settings can be accessed by pressing the + button in the application rule. Just scroll through there and check what settings the program has currently set. I will try to make further screenshots once I am on my pc if I couldn't help right now. Hope this helped :D |
Yep, that fixes it. I'm able to move all my windows from one screen to another reliably now. Thank goodness, I hated having to constantly reach for my mouse to deal with that. Now I can just keep windows open on my second monitor and pull them over as needed instead of constantly minimizing or closing them because they stubbornly refuse to switch monitors without using a mouse. |
WOW! Yeah, it works. I also tried setting up a general window rule in system settings: At first, all my windows were maximised and overlapping, but closing down the applications and restarting them made it behave with tiling. No idea if there are consequences to doing this yet but my quick test, all my windows could now switch between monitors perfectly with the kwin keyboard shortcut. Edit: Ok, setting the system-wide rule wasn't necessarily the best idea - Chrome worked for a while like this but then mysteriously stopped working after a long session, but applying the rule + normal window forcing on Chrome as @DashieTM showed above for Chrome specifically seems to work fine. Also, I have a few applications (editing tools that don't behave well when scaled down to tile sizes) on the bismuth ignore list, and they then couldn't be maximised without further overrides. Haven't decided yet whether it's more convenient to set a system-wide rule, and override windows that are ignored by bismuth, or just to manually set the maximise/normal window overrides on misbehaving apps as and when encountered. It'd be nice to have a more general solution, but this is OK for most of my daily workflow stuff. I'm not sure if this indicates a way to fix the problem in bismuth alone - I had a go at modifying the typescript code and it didn't seem to have anything that would allow these overrides to be set and unset, for example, automatically when a shortcut is pressed. Maybe in the core cpp code it'd be possible but I haven't dug into that yet. |
Should be fixed in #419 |
Is the change actually live? The problem came back for me a while ago, and from what I can tell anything that would require a window to shrink will cause it to flicker but remain on the same monitor. I'm on Arch using version 3.1.3-1, one of my monitors doesn't have any KDE panels on it so the windows are slightly larger - I can move windows to that monitor, but not from it on X11. I'm gonna go see if it happens on Wayland too just to be sure. |
Just switched from Krohnkite to Bismuth because the former hasn't been updated for quite some time but it was working fine. Running Kubuntu 22.04 with all the latest updates and this problem is still happening despite trying all of the fixes in this and other threads. Wondering why is this bug closed. The problem has been reported by many. Should i open a new bug? |
Summary
If Bismuth is enabled I am unable to move a window to a different screen via the kwin keyboard shortcut. As soon as I disable Bismuth moving a window to a different screen works as expected.
Steps to Reproduce
Expected behavior
With Bismuth enabled, I should be able to use the keyboard to move a window to a different screen.
Screenshots
No response
Bismuth version
Git @ 84a0ac5
KDE Plasma version
5.23.4
The platform KWin is running on
X11
Additional context
No response
The text was updated successfully, but these errors were encountered: