Skip to content
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

Open
cyberhuman opened this issue Jun 18, 2019 · 9 comments
Open

some keystrokes are not captured #9

cyberhuman opened this issue Jun 18, 2019 · 9 comments

Comments

@cyberhuman
Copy link

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.

@asppsa
Copy link

asppsa commented Jun 25, 2019

I'm seeing this as well. Running sway 1.1.1 with two monitors

@nyyManni
Copy link
Owner

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?

@cyberhuman
Copy link
Author

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.

@cyberhuman
Copy link
Author

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.

@nyyManni
Copy link
Owner

I pushed a branch feat/focusing where I do the request for keyboard focus in a different place, could you try that one out?

@cyberhuman
Copy link
Author

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

@nyyManni
Copy link
Owner

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.

@nyyManni
Copy link
Owner

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

@asppsa
Copy link

asppsa commented Jun 26, 2019

@nyyManni, you are right! If I kill swaybar waybar the issue goes away for me too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants