[Bug]: Unable to move window to a different screen

[ehardesty]

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

1. Enable Bismuth Tiling
2. Focus a window and press the shortcut to move a window to a different screen Ex: Meta+Shift+Right
3. Nothing happens
4. Disable Bismuth
5. Focus a window and press the shortcut to move a window to a different screen Ex: Meta+Shift+Right
6. The window moves to a different screen as expected

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

[Moosatronic]

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.

[zany130]

same issue here disabling bismuth fixes it

[lewiji]

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.

[spbisc97]

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. Would be great to make Meta+shift+arrow working

[lewiji]

Since the float - move - unfloat workaround seems to work, I wonder if that could be the default behaviour for when this shortcut is invoked? Unsure if that would mess up layout stuff in other cases, but it seems like the issue is moving a window that's already got a layout applied, and if it can be floated for just long enough to complete the move then it'd work fine for me, barring any visual glitchiness during the initial float.

[spbisc97]

This would mean to overwrite default "change window screen" shortcut on kwin, and I have noticed that not all apps have this behavior. Apps like whatsie and Spotify(I think both electron based) are working pretty fine also when floating layout is not toggled, while others like Libreoffice, Chrome, Discord wont be able to respect my Meta+shift+arrow shortcut ( normal change window screen)

Thanks for this awesome project!

[lewiji]

Apps like whatsie and Spotify(I think both electron based) are working pretty fine also when floating layout is not toggled, while others like Libreoffice, Chrome, Discord wont be able to respect my Meta+shift+arrow shortcut ( normal change window screen)

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.

This would mean to overwrite default "change window screen" shortcut on kwin, and I have noticed that not all apps have this behavior.

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 meta+left click+drag with the mouse is pretty reliable in bismuth for me (though I've seen others report issues around that). It seems like it's able to float the window when the mouse drag starts, and un-float it again when the window is dropped on the other screen - I suspect bismuth is doing this, unless this is a native KWin thing. And I think bismuth would in theory be able to do the same with the "window to screen" shortcut, though I'm completely ignorant to how any of this works and am just guessing, but I haven't even read the code, which I will go do now :)

[linuxthrawn]

Since the float - move - unfloat workaround seems to work, I wonder if that could be the default behaviour for when this shortcut is invoked? Unsure if that would mess up layout stuff in other cases, but it seems like the issue is moving a window that's already got a layout applied, and if it can be floated for just long enough to complete the move then it'd work fine for me, barring any visual glitchiness during the initial float.

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.

[linuxthrawn]

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:

• Alacritty
• Spotify
• LibreWolf
• KCalc
• Emoji Selector
• Kate
• mpv
• vlc
• KSysGuard

Moving programs between screens with keyboard shortcut, not working:

• Dolphin
• Brave
• Vivaldi
• LibreOffice
• Discord
• Viber
• Okular
• System Settings
• System Monitor

[Meister1593]

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:

* Alacritty

* Spotify

* LibreWolf

* KCalc

* Emoji Selector

* Kate

* mpv

* vlc

* KSysGuard

Moving programs between screens with keyboard shortcut, not working:

* Dolphin

* Brave

* Vivaldi

* LibreOffice

* Discord

* Viber

* Okular

* System Settings

* System Monitor

Same for me, but firefox (same engine with librefox) just tries to maximize and doesn't move window to another screen

[heraldofsolace]

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:

• Alacritty
• Spotify
• LibreWolf
• KCalc
• Emoji Selector
• Kate
• mpv
• vlc
• KSysGuard

Moving programs between screens with keyboard shortcut, not working:

• Dolphin
• Brave
• Vivaldi
• LibreOffice
• Discord
• Viber
• Okular
• System Settings
• System Monitor

For me, Dolphin moves fine. But Visual Studio Code doesn't

[rewhile]

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 :|

[HelmicNewciv]

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.

[DashieTM]

https://github.com/Bismuth-Forge/bismuth/issues/360

In there I posted the reason for the bug and how to go around it.

[anotherchu]

#360

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!

[DashieTM]

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. Or by pressing alt+f3 on a open/focused program. In there you open application settings/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

[HelmicNewciv]

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.

[lewiji]

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.

[gikari]

Should be fixed in #419

[HelmicNewciv]

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.

[BearOutThere]

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?