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

alttab behaves incorrectly when Control_R or Alt_R is used to initiate window switch #97

Open
myelsukov opened this issue Apr 8, 2020 · 8 comments
Labels

Comments

@myelsukov
Copy link

I think the bug is here: https://github.com/sagb/alttab/blob/master/src/alttab.c#L521

The if thinks that modifier key is released so it closes the UI before exposing it.
The window is getting switched though.

@sagb
Copy link
Owner

sagb commented Apr 17, 2020

How can I reproduce? alttab -mk Control_R works fine for me.
alttab -mk Alt_R does not, because my window manager uses Alt_R for its purpose. Perhaps you have the problem for the same reason?

@myelsukov
Copy link
Author

myelsukov commented Apr 17, 2020

  1. Start alttab -mk Control_L -w 1 -d 1 -s 1
  2. Now Control_L+Tab works as expected: a window with tiles is shown and you can switch between windows.
  3. Try Control_R+Tab. A window with tiles is not shown, but the focus is moved to the next window. If you keep pressing and releasing Tab without releasing Control_R or if you keep pressing and releasing Control_R+Tab the focus will be switched between the same two windows.

May be this is a feature? 😁
But I think you have a problem with the line I mentioned in the bug report.

@sagb
Copy link
Owner

sagb commented Apr 19, 2020

I doubt it's alttab bug. The line you show is very core logic, I don't see any error here. Have you managed to change/fix the issue by changing this line?
What's your window manager?

@myelsukov
Copy link
Author

myelsukov commented Apr 19, 2020

The logic is flawed. The Alt/Mod1 modifier is triggered by the either L_Alt or R_Alt and it properly intercepted by the alttab.
Then in that line you check if the L_Alt is still pressed. Well, it is not pressed, because I pressed R_Alt so you erroneously decide that L_Alt was released and remove the tiles window.

@sagb
Copy link
Owner

sagb commented Apr 19, 2020

Ah, I got it: you write about the comment "Alt released" in that line. It doesn't mean "Alt" literally, but any modifier set by -mk. Sorry for misleading comment.
Alttab works with various -mk, including Control_R and Alt_R.

If you want to try to resolve your issue, look at window manager key bindings, the question you ignored.

@myelsukov
Copy link
Author

I ignored question about WM as irrelevant 😁
If you are interested, then it's JWM and I personally control all keyboard bindings. Trust me, the keyboard binding has nothing to do with this problem.
The problem is the following:

When you bind the activation hotkey, you bind the keyboard modifier (Ctrl, Mod1, etc) independent on the position of the modifier key: left or right.
So, if you start alttab as alttab -mk Control_L -w 1 -d 1 -s 1 you can trigger it with both Controls: Left and Right (try it if you don't trust me).
But the line https://github.com/sagb/alttab/blob/master/src/alttab.c#L521 tests for the specific control only. In our case it's Left Control.
So, if I trigger alttab with Control_R it gets triggered, the tiles window is displayed then it immediately disappears because that line ⬆️ thinks that Control_L key was released and removes the window. In fact, Control_L was never pressed.

@sagb sagb added the bug label Apr 21, 2020
sagb added a commit that referenced this issue Apr 21, 2020
@sagb
Copy link
Owner

sagb commented Apr 21, 2020

You are right, thank you for pointing out to this. Should be fixed now.

@myelsukov
Copy link
Author

I commented on the commit 😁

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

No branches or pull requests

2 participants