-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
some keystrokes are not captured #9
Comments
I'm seeing this as well. Running sway 1.1.1 with two monitors |
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 |
@nyyManni I tried that branch and it did not fix the issue. |
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... |
I invoke
dmenu-wl_run
viabindsym 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.
The text was updated successfully, but these errors were encountered: