[Bug]: Move window to screen via keyboard shortcut not working with tiling enabled.

[xpufx]

Summary

When trying to move a tiled window to another screen the outcome is inconsistent but mostly it shows an animation like the tiled screen doesn't want to let the window go and it stays where it is. I am not sure if I am missing something or whether this should work at all so this is more a question than a straight bug report. If someone can chime in I can provide more details.

Steps to Reproduce

From tiled window used shortcut key to move window to another screen. Let's say with Meta+Shift+Right .

Expected behavior

Window should go to the next screen and tile or not tile depending on that screen's setup.

Sometimes it is doing something. Probably when in a full screen window/layout. It disappears from the source screen but I can't reliably tell where it went. Sometimes it goes to the next screen as expected.

Screenshots

No response

Bismuth version

bismuth-1649696397.03b522e-3.3.x86_64

KDE Plasma version

5.24.5

The platform KWin is running on

X11

Additional context

No response

[krshrimali]

I'm facing this issue as well.

Versions:

KDE Plasma: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.48-1-MANJARO (64-bit)
Graphics Platform: X11

[krshrimali]

@xpufx - Just curious, do you have window borders disabled while tiling is on? The option is visible in: Window Tiling -> Appearance -> "No borders around tiled windows"

I remember having this issue when the above option was ticked. I've disabled this option, for now the moving window feature works, but I'll update here if it haunts again.

[xpufx]

As far as I can tell "No borders around tiled windows" has no effect. Same result.

I tested a bit more. My shortcuts are set for Window to Next Screen and Window to Previous Screen. These don't sound ideal but are the closest things I could find. I think they would be more useful with directions (left,right,up, down) instead of prev/next.

When I have primary on the left, I can move from secondary to primary without issues. I cannot move anything from primary to secondary, (---UNLESS the window in primary is maximized.-- scratch that. this is not consistent either)

Which shortcuts are you using @krshrimali ?

EDIT: By the way I have since upgraded to plasma 5.25. My current version info:

Plasma: 5.25
Kde framework: 5.94
qt: 5.15.2
X11
Bismuth is still bismuth-1649696397.03b522e-3.3.x86_64

[benemorius]

@xpufx @krshrimali can you test benemorius/bismuth@e35a3e0

[xpufx]

@benemorius This seems to be in /usr/share/kwin/scripts/bismuth/contents/code/index.mjs on my system. How do I test it? Just change it there and log out/in?

[benemorius]

Yes you can change it there if you don't want to compile and install from git. Restarting kwin is sufficient like kwin --replace but also relogging works.

[xpufx]

@benemorius I made the change and tried a bunch of combinations. This seems to be working properly now. (screen next and screen prev are doing the exact same thing but it seems normal for 2 screens since prev and next are the same screen) Thanks!

[krshrimali]

@benemorius I made the change and tried a bunch of combinations. This seems to be working properly now. (screen next and screen prev are doing the exact same thing but it seems normal for 2 screens since prev and next are the same screen) Thanks!

That's great to hear, @benemorius - thank you for sharing the solution.

@xpufx - Can you please clarify what you mean by "screen next and screen prev are doing the exact same thing but it seems normal"?

[xpufx]

@krshrimali As I said before I bound shortcuts to Window to Next Screen and Window to Previous Screen . I have two screens. A bit confusingly I bound these to meta+shift+left and right. What I am saying is since there is always only one screen to go to (i.e the other one) both key combinations are moving the window to the other screen. I am assuming if I had three it would first go to the next, then to the one after that.

[krshrimali]

@krshrimali As I said before I bound shortcuts to Window to Next Screen and Window to Previous Screen . I have two screens. A bit confusingly I bound these to meta+shift+left and right. What I am saying is since there is always only one screen to go to (i.e the other one) both key combinations are moving the window to the other screen. I am assuming if I had three it would first go to the next, then to the one after that.

Ah got it, the bindings are the same for me! I'm gonna try this fix now!!!! If it works, this is AMAZING!!!!

[krshrimali]

Okay, this seems to fix for all other windows except for Google Chrome. Anything wrong? I couldn't record the full 2 monitor setup, since I'm using a vertical monitor, but here is how it looks on the primary monitor - the flickering with the chrome window is what is a little buggy, @xpufx - do you use google chrome as your main browser? Can you please check if it's also an issue with you?

Video: https://www.youtube.com/watch?v=qGjgpE-qAzo

[xpufx]

I have chrome and it's working fine. The only peculiarity is if it's maximized it's moving to the next screen as if it's a floating window. In other words it stays maximized and does not snap into the grid. I think this is true for all maximized windows.

EDIT: Does it behave differently if you flip "Use system titlebar and borders" ?

[krshrimali]

I have chrome and it's working fine. The only peculiarity is if it's maximized it's moving to the next screen as if it's a floating window. In other words it stays maximized and does not snap into the grid. I think this is true for all maximized windows.

EDIT: Does it behave differently if you flip "Use system titlebar and borders" ?

Weird, why is it just me :/ I tried flipping the "Use system titlebar and borders" option, and the behavior is still buggy. Though, only for Google Chrome. Can it be about the chrome version I'm using? Mine is: Version 102.0.5005.115 (Official Build) (64-bit) - may I ask which one is yours (version)?

[benemorius]

The flickering is due to kwin moving the window and then bismuth immediately moving it back. The appearance varies and looks glitchy based on how quickly the rapid window movements are rendered.

I'm not able to reproduce it with chromium or chrome though.

Google Chrome 102.0.5005.115 
Chromium 102.0.5005.115
kwin 5.25.0

@krshrimali by chance do you have some custom window rules in kwin that could cause it?

[krshrimali]

Ah, yes, flickering is fine if it works :( I have no window rules here:

Maybe, it can be about kwin's version? I'm sorry to trouble you with this though :/

[benemorius]

What version of kwin are you running? (kwin --version)

I can try to reproduce it on older versions, but I think it's more likely to be related to chrome specifically. Historically chrome loves to do undesirable things with window placement in my experience, but that's just a hunch.

Can you paste the output from kwin during a single attempt at moving a chrome window? Open a konsole and run kwin --replace &, then prepare to move a chrome window, then clear the noisy output in the terminal (ctrl-shift-k), then finally attempt to move a chrome window, then copy the resulting terminal output before it adds much more noisy output and paste it here.

Example:

org.kde.bismuth: moveResizedChanged,[object Object]
org.kde.bismuth: moveResizedChanged,[object Object]
org.kde.bismuth: onWindowMoveOver,[object Object]
org.kde.bismuth: onWindowGeometryChanged,[object Object]
org.kde.bismuth: arrange
org.kde.bismuth: onWindowChanged,[object Object]
org.kde.bismuth: arrange

[krshrimali]

@benemorius - Woke up this morning, and things work. Btw, I did kwin_x11 --version and it is 5.24.5 - I hope switching to 5.25 will be no pain <3

The thing with chrome I realized today was, probably it was in maximized mode and I didn't realize. Something went wrong yesterday, today I made sure that chrome is also in tiling mode, and then the shortcuts work for moving it to the next/prev screen. Can you please create a PR with your fix here? I think it's great that we have people like you looking at it, and helping improve. I'm very sure that Bismuth needs attention from the community <3

I'll try the fix for the whole day today, and let you know if there is anything that doesn't work.

[krshrimali]

Hi, @benemorius - I am facing the issue again, I followed the steps you suggested, and here is the output I got:

org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrange
org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrangeScreen/finished,[object Object]

Is something fishy here? :/

[krshrimali]

Live demo: https://www.youtube.com/watch?v=AbRLEkKKKu4

[krshrimali]

Hi, @benemorius - I am facing the issue again, I followed the steps you suggested, and here is the output I got:

org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrange
org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrangeScreen/finished,[object Object]

Is something fishy here? :/

I observed, for other windows, it's just this output:

org.kde.bismuth: arrange
org.kde.bismuth: arrangeScreen/finished,[object Object]
org.kde.bismuth: arrangeScreen/finished,[object Object]

For chrome, it's the 6 lines output, so probably something buggy?

[krshrimali]

I installed Microsoft Edge on Linux just to check if it's just chrome, and the issue was there for Edge as well. If I'm not wrong, it's a GTK app, does it have to do with GTK?

Also, I re-installed Google Chrome, and initially it was moving just fine to the next screeen but when I maximized it and got it back to the tiling arrangement, it started showing the same buggy behavior... Probably this can help? @benemorius

[krshrimali]

I just disabled a few options in Window Tiling Behavior:

1. Untile windows by dragging
2. Floating windows always on top

(System Settings -> Window Management -> Window Tiling -> Behavior)

And this seems to have fixed the issue for Google Chrome. I'll confirm again after a day of experimentation. :) Opened a new chrome window just now, and it failed again. :/ Sorry, false alarm, this isn't fixed for me yet. :(

[xpufx]

@krshrimali I watched your video. My setup does not behave that way at all. I am able to move chrome around (after the fix) just like any window. We can compare configs/versions if you want to see what's different. We can do this interactively if you join the #kde channel on libera chat or in the Bismuth room on matrix.

Are you sure you applied the change benemorius propsed properly?

[krshrimali]

@xpufx - Thank you so much for offering help. I've joined the kde channel on libera, my username is krshrimali there. How should I get in touch with you there?

I'm sure that I applied benemorious' suggestion, as it fixes for other windows except for Chrome.

[krshrimali]

I can't fail to acknowledge how just 5 mins of matching the configs with @xpufx helped save my day!! Thank you so much @xpufx again.

Here is what worked, I enabled the "Spawn windows at: Master area" option in Window Tiling behavior, and it fixed it for me. Is this how it's supposed to work? Or is it a buggy behavior, not so sure, but I'll appreciate any thoughts on this.

cc: @benemorius @gikari :)

[krshrimali]

I can't fail to acknowledge how just 5 mins of matching the configs with @xpufx helped save my day!! Thank you so much @xpufx again.

Here is what worked, I enabled the "Spawn windows at: Master area" option in Window Tiling behavior, and it fixed it for me. Is this how it's supposed to work? Or is it a buggy behavior, not so sure, but I'll appreciate any thoughts on this.

cc: @benemorius @gikari :)

Okay, for what it's worth, none of the fixes help. After reboot, it breaks again. :(

[nitou2504]

Hi, i'm facing the same issue. I tried various configurations, just like the ones in this thread, including recompiling with the possible fix. However it didn't work until I used kwin --replace. Then it broke after opening 3 windows. And only allowed me to change monitors if the window was maximized. I have to mention that there's no issue when moving the window using the mouse instead of the shortcut.

KDE Plasma: 5.25.1
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5
Kernel Version: 5.15.49-1-lts
Graphics Platform: X11