Closed jjgalvez closed 2 years ago
Thanks for your report. I already received one report about keyboard issues in Wayland. Despite this user says the issue is gone in version 1.1, I'd still suggest you to try latest test version from the dev branch. I recently pushed few changes there, which could resolve possible issues with keyboard.
For this you'd need to:
Note I have to have more than one program running otherswise meta-uparrow does not activate snap-assist
This is actually the intended behavior :) When you only have one window open, assist will not show up because there's no other window to suggest.
Just tried the dev branch, and I'm having the same issue. unable to type until snap-assist has been activated and dismissed
Did you tried re-login in Plasma after installing the dev branch version? Disabling/enabling the script in system settings?
It is normal for the script to absorb keyboard events while it's visible on screen (to make arrow key selection work), but it should not do it while assist is not on the screen (closed with cross button, for example)
I found out why this happens on my end at least. When launching the script first time on wayland, there's a teeny tiny window appearing on top left corner of my monitor. When moved and resized it looks like this:
My guess is that the script, on first activation, makes it visible on screen on Wayland even if it's not doing anything. However if I close it, the script stops working.
If I do the snap-assist once after that tiny window appears, then keyboard starts working again.
Same issue here. Also Arch+Wayland combo.
-`
.o+` ---------------------
`ooo/ OS: Arch Linux x86_64
`+oooo: Host: B450M DS3H V2
`+oooooo: Kernel: 5.18.16-zen1-1-zen
-+oooooo+: Uptime: 8 mins
`/:-:++oooo+: Packages: 1190 (pacman), 62 (flatpak)
`/++++/+++++++: Shell: zsh 5.9
`/++++++++++++++: Resolution: 3840x2160
`/+++ooooooooooooo/` DE: Plasma 5.25.4
./ooosssso++osssssso+` WM: kwin
.oossssso-````/ossssss+` Theme: [Plasma], Breeze [GTK3]
-osssssso. :ssssssso. Icons: [Plasma], breeze-dark [GTK2/3]
:osssssss/ osssso+++. Terminal: alacritty
/ossssssss/ +ssssooo/- CPU: AMD Ryzen 7 3700X (16) @ 3.600GHz
`/ossssso+/:- -:/+osssso+- GPU: AMD ATI Radeon RX 6600/6600 XT/6600M
`+sso+:-` `.-/+oso: Memory: 2838MiB / 15916MiB
`++:. `-/+/
.` `/
I read about this a bit more and it seems Wayland doesn't have support for QWindow::requestActivate()
which is what is causing it to fail.
Interesting, so are Wayland users basically out of luck for the time being?
requestActivate()
is called in the script only once, before assist is about to show. And since people tend have the issue right after the boot, before any snap and script activation, there must be another problem.
Underlying mechanics of the script is that it always keeps it's window open, just off-screen, empty and minimized when not needed. My suggestion would be, that under some circumstances it continues to steal keyboard focus and events while being off-screen and inactive. I say "some", because I still didn't manage to reliably reproduce it in my Wayland session.
In the dev branch I commented out a few lines which could in theory mess up with keyboard focus, but if you can confirm that this fix is not working, we need to look somewhere else. The fact that you were able to see the empty assist window right after boot could give a hint, as this is unintended behavior as well.
I just installed from dev, re-logging in after installing and I am still having the issue right as soon as I log in.
Issue still persist for me as well. It just seems to eat all inputs, until I quick tile a window and it appears normally.
My suggestion would be, that under some circumstances it continues to steal keyboard focus and events while being off-screen and inactive.
It is my understanding that it is not possible. Wayland by design does not let applications listen to events or keystrokes when the window is not focused, grab focus of the desktop or any other "intrusive" operation.
The only way is to find a workaround to having a window that records the user events (maybe using xdg portals?)
Could you perhaps try to get the input through KWin?
I think I managed to find a fix for this issue — please test the latest dev branch code. The downside is, it now shows window's show-up animation on appear (scale up in my case).
just tried the latest dev version and it looks like it's working! Its a little difficult to see which layout you are selecting, but that may just be me. Thanks for getting this working with wayland so qucikly!
It works! :tada:
Well, it's too soon to celebrate! Turns out on X11 session this fix causes the assist window to be completely black and empty on any second appear
I think I just managed to fix it in dev branch by removing a line, and now keyboard issue in Wayland should not happen, as well as "black window bug" in X11.
Would be glad if somebody could test!
Thank you dev, appreciate the work 😁
Cant test X11 but seems to work for me. Thanks for the quick response, this script adds a lot to usability. May wanna try pitching it as a built in KDE feature perhaps? ;)
Please feel free to reopen if the issue will happen again! I guess I'll publish an update with this fix in the store today or tomorrow
try pitching it as a built in KDE feature
No need to, it's already being pitched for quite a while :)
just tested the dev instance and it looks like it's working! Thank you so much!
Hi, first very cool program. I am getting an odd error. when I first login if I open a single app (eg kate) I cannot type into it. If I start a second program (eg dolphin) and activate snap-assist with meta-uparrow being able to type into applications is restored. Note I have to have more than one program running otherswise meta-uparrow does not activate snap-assist. Disabling snap-assist also restores functionality.
Happy to provide what ever logs might be helpful OS Arch plasma 5.25.4 display server = wayland