<div dir="ltr"><div>> So long as there's no limbo state, that will work reliably.</div><div><br></div><div>The limbo state is baked into this particular cake.<br></div><div><br></div><div>> Perhaps a non-destructive peek ahead at the native event queue ?</div><div><br></div><div>I thought this is why Niels was talking about a small timeout for the "focus lost" event. We are all on the same page or so it seems to me.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 25, 2023 at 7:34 AM Philip Race <<a href="mailto:philip.race@oracle.com">philip.race@oracle.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">X11 doesn't conveniently tell you this either.<br>
<br>
The JDK code for X11 just asks for the X11 window which has focus now <br>
and sets that<br>
as the "opposite" window in the focus lost event.<br>
So long as there's no limbo state, that will work reliably.<br>
<br>
If wayland doesn't let you directly ask which of this application's <br>
windows have focus, then it<br>
could be a bit more tricky, because you'd need to wait for the focus in <br>
event which<br>
might mean processing pending events looking for it.<br>
Perhaps a non-destructive peek ahead at the native event queue ?<br>
<br>
-phil.<br>
<br>
<br>
On 11/23/23 9:51 AM, Niels De Graef wrote:<br>
> Hi Maxim,<br>
><br>
> On Wed, Nov 22, 2023 at 8:36 PM Maxim Kartashev<br>
> <<a href="mailto:maxim.kartashev@jetbrains.com" target="_blank">maxim.kartashev@jetbrains.com</a>> wrote:<br>
>> Thanks, Niels!<br>
>>> you'll get a leave for the first window and an enter for<br>
>>> the second, and from there you can connect the dots<br>
>> Right, but it's the connecting the dots part that gives me the trouble. These events aren't connected in any way that I can imagine. The second one may not actually come at all if the user has switched to another app and then never returned to this one.<br>
> I can only think of 2 possible suggestions at the moment (and if<br>
> others have a better idea, please do reply):<br>
><br>
> 1. Schedule each "window lost focus" with a tiny timeout on ::leave.<br>
> We can probably assume that the ::enter event will be propagated soon<br>
> enough anyway, and if it does, you could try to change the event you<br>
> scheduled earlier to add that parameter. (if the event _does_ take a<br>
> while, it's imo arguably okay to say your app actually lost focay)<br>
><br>
> 2. Send 2 events and don't try to correlate them. In other words, send<br>
> a "window focus lost" event with a null pointer on ::leave and send<br>
> another one _with_ that pointer on ::enter. I'm not sure how java<br>
> apps/jdk might react to that though.<br>
><br>
> -- Niels<br>
><br>
>> On Wed, Nov 22, 2023 at 10:06 PM Niels De Graef <<a href="mailto:ndegraef@redhat.com" target="_blank">ndegraef@redhat.com</a>> wrote:<br>
>>> Hi Maxim,<br>
>>><br>
>>> I asked around a bit, and one of the GTK developers replied that you<br>
>>> might be interested in wl_keyboard's enter [1] and leave [2] events<br>
>>> (note that several other related objects have similar events).<br>
>>><br>
>>> Basically, you'll get a leave for the first window and an enter for<br>
>>> the second, and from there you can connect the dots<br>
>>><br>
>>> -- Niels<br>
>>><br>
>>> [1]: <a href="https://wayland.app/protocols/wayland#wl_keyboard:event:enter" rel="noreferrer" target="_blank">https://wayland.app/protocols/wayland#wl_keyboard:event:enter</a><br>
>>> [2]: <a href="https://wayland.app/protocols/wayland#wl_keyboard:event:leave" rel="noreferrer" target="_blank">https://wayland.app/protocols/wayland#wl_keyboard:event:leave</a><br>
>>><br>
>>> On Wed, Nov 22, 2023 at 5:22 PM Maxim Kartashev<br>
>>> <<a href="mailto:maxim.kartashev@jetbrains.com" target="_blank">maxim.kartashev@jetbrains.com</a>> wrote:<br>
>>>> Hi, All!<br>
>>>><br>
>>>> I've got another Wayland-related question:<br>
>>>> In Java, the "window lost focus" event has a property that points to the window that got the focus instead, if any. In essence, an event without that property means that the focus is now in another app, while non-null property means that some other window of our app still got it.<br>
>>>><br>
>>>> I wonder if you could help me to determine if this is implementable in Wayland?<br>
>>>><br>
>>>> Thanks in advance,<br>
>>>><br>
>>>> Maxim.<br>
>>>><br>
<br>
</blockquote></div>