Closed amosbird closed 2 years ago
Temporary workaround: rofi -steal-focus
Can you give some specific info on how it interferes?
Can you give some specific info on how it interferes?
The key mapping gets activated for rofi window which shouldn't.
What key mapping exactly, could you please be more specific? Could you provide specific step-by-step example (and a tiny config snippet) to reproduce what you are seeing as well as describe:
Hmm, it should be very intuitive to reproduce. Any key bindings in xkeysnail will override related rofi keys if the current window is matched by some rule. I think rofi -steal-focus
is good enough.
Hmm, it should be very intuitive to reproduce.
These are famous last words... that might be true, but very often it's not. Having small, reproducible test cases can often save maintainers hours of time.
Thanks for closing issue. I'm glad that works for you... but if it was a genuine bug I'd love to see it fixed, and if it's just something that people need to be aware of with Rofi then we should add it to a FAQ, etc... anyways if you ever have time in the future - you might be helping out others in similar setups.
@joshgoebel, I think I can add a few details on that, faced this problem, too :)
Let's say, I have these mappings defined -- for everything except terminal emulators:
terminals = ["gnome-terminal","xterm","kitty","alacritty"]
define_keymap(lambda wm_class: wm_class.casefold() not in terminals, {
K("LCtrl-E") : K("END"),
K("LCtrl-A") : K("HOME"),
})
Now, for instance, if while being in kittty
, I launch rofi
, then pressing <Ctrl-a>
and <Ctrl-e>
in rofi
works as expected moving the cursor in the input bar to the beginning and to the end of the entered string.
However, if I launch rofi
while being, let's say, in a browser, then <Ctrl-a>
and <Ctrl-e>
act like <Home>
and <End>
keys, moving the cursor to the first and to the last entries in the list view.
In other words, rofi
seems to somehow inherit xkeysnail
's mappings from the underlying application. And, unfortunately, the mentioned rofi
's option -steal-focus
doesn't actually solve it for me.
(Don't really know who is exactly to blame for this behaviour, rofi
, or xkeysnail
, but just found this issue and decided to add some context :).
Our whole "which app is active" behavior is based on which app is focused (per X) so if Rafi does NOT steal focus it's going to always be broken.
Asking it to steal focus sounds like the correct fix now that I understand the issue better.
The funny thing, though, it doesn't work for me:
I add rofi
to the list of exceptions:
exceptions = ["xterm","kitty","alacritty","rofi"]
define_keymap(lambda wm_class: wm_class.casefold() not in exceptions, {
K("LCtrl-E") : K("END"),
K("LCtrl-A") : K("HOME"),
})
Then add -steal-focus
option to the rofi
call.
And yet, if spawned in front of a browser, for instance, LCtrl-E
acts exactly as END
. (Disabling these mappings make the problem go away, so this is definitely the culprit, and not something else :).
Nevermind, it works :)
And thanks for the explanations.
When rofi window is active, the wmclass rule should be disabled. Currently it interferes with the keyboard setting of rofi.