nyyManni
some keystrokes are not captured
I invoke dmenu-wl_run via bindsym Mod1+F2 exec dmenu-wl_run in sway. It appears to capture most of the key presses, but some of them are received by the currently focused window instead, which is quite a nuisance.
It looks like the window that dmenu-wl and the active window compete for the focus, and dmenu-wl wins most of the time, but not always. E.g. I see my Kitty terminal briefly changes the cursor shape as if it has the input focus, and it consumes key presses during that interval.
I was not able to reproduce this. So is there a delay before dmenu-wl gains the focus, or does it lose it briefly to the previous client after first getting it?
It loses focus briefly when typing into already focused dmenu-wl. I did not manage to find any pattern of keypresses that leads to losing focus. It happens seemingly randomly.
I just tried on the machine with as single monitor and I can't reproduce it. It happens on two other machines with multiple displays though.
I pushed a branch feat/focusing where I do the request for keyboard focus in a different place, could you try that one out?
@nyyManni I tried that branch and it did not fix the issue. In fact, I feel like the problem became worse. Now the bar is not focused for a few seconds after starting, and after it gets the focus, periods of losing the focus are longer.
Hhhhmm.
I can now replicate at least a similar issue: if I hold the modifier key for a longer period of time after dmenu has opened, I can consistently make it lose the focus back to the other client. Interestingly, this happens only if I run it on the secondary monitor.
Some progress, at least now I know what is stealing the focus from dmenu. If I kill swaybar, everything works as expected. I think swaybar has a refresh interval of one second, it seems that if that refresh happens when you are still holding the modifier for dmenu, the focus is lost. That explains why the behavior is somewhat random.
The adventure continues...