Peek: In conjunction with key-mon, peek window steals focus

[Moini]

I'm using key-mon (from official ubuntu repos) and peek (from stable ppa) on Linux Mint 18 (Ubuntu 16.04 base).
When I try to record a gif with key-mon activated at the same time as peek, the peek window always regains focus automatically.
I.e. I click into the Inkscape window below, and want to do an action like Copy-Paste, but as soon as I do no longer click or otherwise use the mouse to interact with the Inkscape window, focus returns to the peek window. This only happens when I use key-mon in parallel.
Would it be possible to have both apps running, and still be able to lend focus to the window I'm working in permanently, so keyboard shortcuts can be used? (trying to make short tutorial gifs)

[phw]

I have no good explanation right now why this might be happening. I will try to reproduce this, but Peek does not actively try to grab the focus, so I hope I can find anything.

[Moini]

Thank you!
Additional info that may help with reproducing: I'm using the Xfce desktop, and it's actually LM 18.1 (always forget...)

[phw]

Some status update: I could not reproduce this with just key-mon on my system (Arch Linux, Gnome).

Next up is testing this with Xfce on my Ubuntu 16.04 VM.

[Moini]

Just tested again to make sure it's consistent (it is). Also tested with other programs (e.g. Thunderbird). As soon as I do no longer actively hold down a mouse button, focus goes to the peek window (can be identified by the active window listing in the task bar).

[Moini]

In case it's important:
Settings in Xfce settings manager for Window behaviour specifics (sorry, no idea what it's in English, German interface here):

• prevent loss of focus and
• take normal ICCCM focus hint into account
  are checked.
  (unchecking 'prevent loss of focus' doesn't make a difference (rebooted))

[phw]

So I am completely puzzled and cannot reproduce this at all. First I installed Xfce4 on my Ubuntun 16.04 VM. I installed key-mon from official repositories and peek from stable PPA and also tried freshly compiled from source. This is what I do:

1. I open key-mon and peek (tried both first starting once, than another)
2. I click on start recording
3. I click inside the Peek window to focus the application underneath (tried with gedit, tilix and nautilus)
4. I start interacting with the window below using my keyboard (e.g. typing commands in terminal, writing text in gedit, copy pasting etc.)

At no point could I trigger the peek window to grab the focus. I also tried with various XFCE focus related settings in Window Manager and Window Manager Tweaks, most importantly I enabled and disabled the two you had mentioned (they are called "Activate focus stealing prevention" and "Honor standard ICCCM focus hints" in English).

I also did the same on another VM with Linux Mint 18.1 installed. I am out of ideas right now :(

[Moini]

Thank you very much for this thorough testing, @phw .

Can you think of anything that I could try to help figure out the issue?
(just tried the Windows method: uninstall/reinstall, and even purge - but didn't help, either)

E.g. is it possible to somehow log what's happening?

It might be that it's due to some older component on my system - I had upgraded from the previous LTS version (last year), and who knows what that did... It certainly didn't go 100% smooth.

Did you also get any key-mon warnings, like this:
"/usr/local/lib/python2.7/dist-packages/keymon/shaped_window.py:78: Warning: Source ID 323 was not found when attempting to remove it"
gobject.source_remove(self.timeout_timer)

[phw]

Did you also get any key-mon warnings, like this:
"/usr/local/lib/python2.7/dist-packages/keymon/shaped_window.py:78: Warning: Source ID 323 was not found when attempting to remove it"
gobject.source_remove(self.timeout_timer)

No, I didn't. But this is actually interesting, as things installed in /usr/local are not from official packages. Maybe you had an old version installed manually in /usr/local. Try the output of which key-mon, I am pretty sure this will show /usr/local/bin/key-mon. Try removing all key-mon related files from /usr/local and then run the system installed key-mon in /usr/bin/key-mon

If this still does not solve the issue you could look at the output in journalctl -f if there is anything suspicious while this happens.

[Moini]

Ha - you're right, thank you, phw!
I had a self-compiled version (with some fixes that made the click indicator more stable and something that was specifically changing settings for my keyboard) installed, long ago, I now remember.

I had thought that the later version would have superseded the old one, but obviously, that wasn't the case.

Unfortunately that crazy click-indicator-doesn't-go-away-if-I-click-and-drag issue in key-mon is back now, and the focus issue is still there, but it's inconsistent now. It seems to be dependent on click-drag, timing and other mouse movements... When I change the mouse position, and click in a different place, focus goes to peek. When I only click in the same position, focus stays in clicked window.

But if I disable the 'highly visible click' in key-mon settings, then it works as expected! I liked the click-indicator, but it's less important than the focus for keyboard shortcuts. Clicks will still show in the mouse symbol.
(I'd be curious if you can reproduce the inconsistent behaviour with the highly-visible click turned on - maybe that steals focus temporarily and doesn't return it to the correct window that had it before... But that would be a key-mon issue, not a peek issue, I guess).

[Moini]

No output of 'journalctl -f' during test.

Just for completeness, a gif (look at task bar and mouse indicator to see what happens with focus and clicks):

Probably, this can be closed? I assume it's more of an issue with key-mon... :-/

[phw]

Indeed, with activated "Highly visible click" I can reproduce the issue. Interestingly it is always Peek gaining the focus, no matter where you click (inside the Peek window or completely elsewhere). This is related to the fact that Peek is set to be displayed always on top of other windows. I can also reproduce this by setting any other window to always on top (by right clicking on the window header). That window will then behave exactly as Peek.

Probably, this can be closed? I assume it's more of an issue with key-mon... :-/

Yes, this seems to be an issue with key-mon (maybe in combination with the XFCE window manager, as I cannot reproduce e.g. on Gnome). I guess for the click highlighting to work it has to change the focus, and key-mon probably contains some code to give the focus back, which fails here. I am curious and want to look into the key-mon code to confirm that, so I keep this issue open a bit. But I currently do not expect that I can do anything in Peek about it :(

[Moini]

Thank you for all your help with this - you helped even though it turned out to not be related to peek. If you ever need any help with Inkscape, please let me know :)

[Lenbok]

I have the same problem of not being able to interact with the apps underneath peek. In my case I do not use key-mon, but I do use focus-follows-mouse in my window manager (window maker with compton). Peek is constantly on top, grabbing focus so there is no way to interact with the underlying apps that I am wanting to record. If I use alt-tab to select the underlying app, peek re-pushes itself to top, re-grabbing the focus.

Should I file a separate issue?

[phw]

@Lenbok Yes, yours is a separate issue. This one is specifically about key-mon.

But also in your case I don't think I can do anything, this is in the responsibility of the window manager. Peek can do nothing against the window manager giving it the focus. The workaround is to disable focus follows mouse while recording.

If you think the window manager should be clever enough to take cut out areas of windows into account when focus follows mouse is active file a bug against Window Maker