<div dir="ltr">We're on the same page: possibility #2 is what I'm doing now and possibility #1 is what I think I'll have to do, but on the "client" side, i.e. outside of JDK.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 23, 2023 at 9:51 PM Niels De Graef <<a href="mailto:ndegraef@redhat.com">ndegraef@redhat.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">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>
><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>
<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>
>><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>
>> ><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>
<br>
</blockquote></div>