You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a shell script that calls rofi in ~/bin/. This script is called with a keyboard shortcut set up with Plasma system settings. To reproduce just press the keyboard shortcut on an empty desktop.
Expected behavior
I can type and rofi narrows the given list.
Actual behavior
My keypresses go "nowhere" for Plasma seemingly, so it opens KRunner and my input goes there.
Additional information
Yes, I use Wayland, and I read #446 and the wiki page. I was hoping maybe this bug could be addressed on the XWayland side without getting into native Wayland support. Or that this is actually a Plasma bug that I can report there.
It only happens when no other window is visible on the desktop (they can be minimized, or just that there isn't anything open). As long as any other window is visible, the keypresses go into rofi as expected.
System versions:
Linux 5.15.161
Slackware64 15.0
Plasma 5.23.5
Wayland 1.22.0
Xwayland 21.1.4
plasma-wayland-protocols-1.6.0
kwayland-5.90.0
Using wayland display server protocol
No, I don't use the wayland display server protocol
I've checked if the issue exists in the latest stable release
Yes, I have checked the problem exists in the latest stable version
The text was updated successfully, but these errors were encountered:
I think this is not a rofi bug, it looks like (but not sure with this information) that rofi is not allowed to grab the keyboard on an empty desktop.
I have no idea how this is handled in Xwayland/wayland/etc.
If somebody with more knowledge can look into this? but I don't run wayland or Xwayland and have no way to debug.
I strongly recommend using @lbonn his wayland port of rofi if you use wayland.
I would like to try @lbonn's port but your version is packaged for my distro (https://slackbuilds.org/repository/15.0/desktop/rofi/ – this repo is similar to Arch's AUR) and the port uses a different build system. I'll take a stab at it now but I don't have a much energy to spend on it.
ETA: Oh well, I didn't get far.
Dependency glib-2.0 found: NO found 2.70.3 but need: '>= 2.72'
@j12i we also have this issue open on the wayland fork lbonn#121 but you seem to be running mainline rofi.
rofi on XWayland has issues that cannot really be worked around I am afraid.
Rofi version (rofi -v)
Version: 1.7.5
Configuration
https://gist.github.com/j12i/ecfd1c92e9d413a6ab2fb71b9dee8a5b
Theme
https://gist.github.com/j12i/1224d9df6c196c4025eab19cd4b4a364
Timing report
No response
Launch command
rofi -dmenu -i
Step to reproduce
I have a shell script that calls rofi in ~/bin/. This script is called with a keyboard shortcut set up with Plasma system settings. To reproduce just press the keyboard shortcut on an empty desktop.
Expected behavior
I can type and rofi narrows the given list.
Actual behavior
My keypresses go "nowhere" for Plasma seemingly, so it opens KRunner and my input goes there.
Additional information
Yes, I use Wayland, and I read #446 and the wiki page. I was hoping maybe this bug could be addressed on the XWayland side without getting into native Wayland support. Or that this is actually a Plasma bug that I can report there.
It only happens when no other window is visible on the desktop (they can be minimized, or just that there isn't anything open). As long as any other window is visible, the keypresses go into rofi as expected.
System versions:
Linux 5.15.161
Slackware64 15.0
Plasma 5.23.5
Wayland 1.22.0
Xwayland 21.1.4
plasma-wayland-protocols-1.6.0
kwayland-5.90.0
Using wayland display server protocol
I've checked if the issue exists in the latest stable release
The text was updated successfully, but these errors were encountered: