awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.37k stars 598 forks source link

Minimize shortcut sometimes works, sometimes doesn't #1670

Open rogervs opened 7 years ago

rogervs commented 7 years ago

Output of awesome --version:

awesome v4.0 (Harder, Better, Faster, Stronger) • Compiled against Lua 5.3.3 (running with Lua 5.3) • D-Bus support: ✔ • execinfo support: ✔ • RandR 1.5 support: ✔ • LGI version: 0.9.1

How to reproduce the issue:

I have a termite terminal floating above a chromium window which is set to "always on top", which I minimize when I'm just reading and not coding (busy with some tutorials). Sometimes it minimizes first time when I press the minimize shortcut, other times it just "flashes" the terminal. Sometimes it will minimize on the second attempt, but other times it takes like 10 attempts before it minimizes. If I change focus to chromium and then back to the terminal (after a failed minimize attempt), it minimizes first time. I'm running Neovim in the terminal with zsh if that is perhaps relevant.

Any ideas on how I can start figuring out whats going on here?

Veratil commented 7 years ago

Can you try using Mod4 + n (default minimize keyboard shortcut) and see if it has the same problem?

I'm also curious if the tooltip is getting in the way.

rogervs commented 7 years ago

@Veratil I always use Mod4 + n.

Additionally, if I click on the terminal with the mouse, the shortcut works first time after that.

edit: I do not display any toolbars on windows.

psychon commented 7 years ago

Additionally, if I click on the terminal with the mouse, the shortcut works first time after that.

Sounds like a problem with the input focus. Is this issue really about minimisation? Could you check if other client-specific key combinations work? For example, you could add a key combination with function(c) naughty.notify{ text = c.name } end as its callback.

Edit: Oh and: Does typing into the terminal work normally even when awesome's key combination do not work? Edit: And does the same also happen with other programs or is it specific to your terminal? What terminal are you using? Does your terminal also flash if you press a key combination that is not bound by awesome (for example mod4+i)? If so, this might be your terminal's normal reaction to "weird" key presses.

rogervs commented 7 years ago

@psychon I'm still trying to get a hang of lua and specifically the rc.lua for awesome, so I'll do some googling to try out your test case with the additional key combination.

Typing in the terminal works fine even when the awesome key combination does not.

I have successfully recreated the issue using GVIM instead of the terminal.

The flashing appears as though the window actually gets minimized and then almost immediately gets unminimized. I have created a gif of a screen recording to demonstrate what is happening. The gif doesn't pick up the flashing too well, but there is one point where it is quite visible when I have to press the minimize sequence a lot.

minimize

rogervs commented 7 years ago

Ok, so after watching the gif, I noticed that minimize no longer works once my mouse cursor disappears, which is done by unclutter, and it then works again when the mouse cursor appears again (presumably because my palm accidentally touched the touch pad).

I have disabled unclutter and I am no longer able to reproduce the issue.

So that clears up the root cause for this, but it doesn't explain why the window seems to minimize and unminimize very quickly to create the "flashing" effect. Additionally, how do I work around this? (The mouse pointer really annoys me, so I would like to keep using unclutter, or an alternative)

psychon commented 7 years ago

unclutter works by creating an invisible window that contains the mouse cursor. Thus, this window gets the input focus. So far no problem, but when unclutter destroys that window, the input focus shifts around and awesome is informed about this. What happens is:

If awesome is faster, then nothing bad happens (the focus moves away before unclutter destroys its window). If unclutter wins the race, the focus first shifts back from unclutter to your terminal and only afterwards is the window minimised. Awesome learns about this focus change only after minimisation and things that the terminal now has the input focus. Since minimised windows cannot have the input focus, the terminal is unminimised.

A work-around seems to be running unclutter with -grab. A fix would be to teach awesome to handle X11 FocusChange events differently from Lua doing client.focus = c...