mooz / xkeysnail

Yet another keyboard remapping tool for X environment
890 stars 112 forks source link

Conflicts with rofi #142

Closed amosbird closed 2 years ago

amosbird commented 2 years ago

When rofi window is active, the wmclass rule should be disabled. Currently it interferes with the keyboard setting of rofi.

amosbird commented 2 years ago

Temporary workaround: rofi -steal-focus

joshgoebel commented 2 years ago

Can you give some specific info on how it interferes?

amosbird commented 2 years ago

Can you give some specific info on how it interferes?

The key mapping gets activated for rofi window which shouldn't.

joshgoebel commented 2 years ago

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:

  1. exactly what happens
  2. exactly what you were expecting to happen instead
amosbird commented 2 years ago

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.

joshgoebel commented 2 years ago

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.

097115 commented 1 year ago

@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 :).

joshgoebel commented 1 year ago

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.

097115 commented 1 year ago

The funny thing, though, it doesn't work for me:

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

097115 commented 1 year ago

Nevermind, it works :)

And thanks for the explanations.