<div dir="ltr">Sorry, randomly saw this, and don't know the full context, so sorry if this is a rehash of what you've already looked at, or I didn't understand what you're trying to fix.<div><br></div><div>But shouldn't you be doing the normal focus lost / gain notification, but instead paying attention to the EnterNotify for this condition? When the WM ungrabs the pointer, you won't necessarily receive a Focus In, but rather you should always receive an EnterNotify, and I believe it should have mode = NotifyUngrab and a detail of NotifyAncestor. In that condition, you could send the WM_ACTIVATE at that time and not try to track the focus gained / lost, which you may not get? For example, playing w/ xev under the awesome WM, when I use the hotkey + mouse to move a window, the window doesn't lose / gain focus while that happens, but it does receive the EnterNotify with the above conditions when the WM finishes the move.</div><div><br></div><div>Kimball</div><div><br></div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 8:11 PM Rémi Bernon <<a href="mailto:rbernon@codeweavers.com">rbernon@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/19/19 1:09 PM, Alexander Julliard wrote:<br>
> Rémi Bernon <<a href="mailto:rbernon@codeweavers.com" target="_blank">rbernon@codeweavers.com</a>> writes:<br>
> <br>
>> Because on X11 we cannot accurately reproduce the proper non-client<br>
>> messages sequence when using decorated windows, applications sometimes<br>
>> assume it is safe to call ClipCursor with a rectangle that matches the<br>
>> current window position as soon as they receive a WM_ACTIVATE message.<br>
>> When the WM finishes moving the window, and since commit<br>
>> 92177b0b161e91f1d609615d89d8e3199feea33f we would retry to clip the<br>
>> cursor with an incorrect rectangle.<br>
>><br>
>> Before the WM starts moving a window, an active pointer grab is usually<br>
>> initiated and we can use the result of XGrabPointer to decide whether<br>
>> the window is really focused or if we should wait until the WM has<br>
>> finished.<br>
>><br>
>> This adds a pseudo modal loop that waits for XGrabPointer to succeed -<br>
>> without any confine window to avoid spurious cursor movements - before<br>
>> notifying the applications of FocusIn events.<br>
> <br>
> I don't think that's not a good idea. We used to have waits at various<br>
> points to try to synchronize with the WM, but in the end it causes more<br>
> trouble than it's worth. There's always some WM that doesn't follow the<br>
> expected sequence, and then you get long timeouts and deadlocks. You<br>
> need to find a way to make this work asynchronously.<br>
> <br>
<br>
 From my investigation it looks to me so far that calling XGrabPointer <br>
is the most "reliable" way - and so far the only way - to tell if a <br>
window manager is manipulating a window or not, and if there's some WM <br>
out there that do not grab the cursor while moving their window... well <br>
it's going to be the same as the current situation where applications <br>
assume they can freely control the cursor.<br>
<br>
Then there could theoretically be some environments where it is not <br>
possible to ever grab the pointer, in which case I don't see any <br>
practical solution to this.<br>
<br>
If it is better, it could be possible to delay the processing of FocusIn <br>
events until the grab succeeds. Retrying on every new event instead of <br>
actively waiting for it. Of course, if it is not possible to grab the <br>
pointer at all, then we're screwed as well.<br>
-- <br>
Rémi Bernon <<a href="mailto:rbernon@codeweavers.com" target="_blank">rbernon@codeweavers.com</a>><br>
<br>
</blockquote></div>