Client keyboard focus

[Philip Race]

X11 doesn't conveniently tell you this either.

The JDK code for X11 just asks for the X11 window which has focus now 
and sets that
as the "opposite" window in the focus lost event.
So long as there's no limbo state, that will work reliably.

If wayland doesn't let you directly ask which of this application's 
windows have focus, then it
could be a bit more tricky, because you'd need to wait for the focus in 
event which
might mean processing pending events looking for it.
Perhaps a non-destructive peek ahead at the native event queue ?

-phil.


On 11/23/23 9:51 AM, Niels De Graef wrote:
> Hi Maxim,
>
> On Wed, Nov 22, 2023 at 8:36 PM Maxim Kartashev
> <maxim.kartashev at jetbrains.com> wrote:
>> Thanks, Niels!
>>> you'll get a leave for the first window and an enter for
>>> the second, and from there you can connect the dots
>> 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.
> I can only think of 2 possible suggestions at the moment (and if
> others have a better idea, please do reply):
>
> 1. Schedule each "window lost focus" with a tiny timeout on ::leave.
> We can probably assume that the ::enter event will be propagated soon
> enough anyway, and if it does, you could try to change the event you
> scheduled earlier to add that parameter. (if the event _does_ take a
> while, it's imo arguably okay to say your app actually lost focay)
>
> 2. Send 2 events and don't try to correlate them. In other words, send
> a "window focus lost" event with a null pointer on ::leave and send
> another one _with_ that pointer on ::enter. I'm not sure how java
> apps/jdk might react to that though.
>
> -- Niels
>
>> On Wed, Nov 22, 2023 at 10:06 PM Niels De Graef <ndegraef at redhat.com> wrote:
>>> Hi Maxim,
>>>
>>> I asked around a bit, and one of the GTK developers replied that you
>>> might be interested in wl_keyboard's enter [1] and leave [2] events
>>> (note that several other related objects have similar events).
>>>
>>> Basically, you'll get a leave for the first window and an enter for
>>> the second, and from there you can connect the dots
>>>
>>> -- Niels
>>>
>>> [1]: https://wayland.app/protocols/wayland#wl_keyboard:event:enter
>>> [2]: https://wayland.app/protocols/wayland#wl_keyboard:event:leave
>>>
>>> On Wed, Nov 22, 2023 at 5:22 PM Maxim Kartashev
>>> <maxim.kartashev at jetbrains.com> wrote:
>>>> Hi, All!
>>>>
>>>> I've got another Wayland-related question:
>>>> 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.
>>>>
>>>> I wonder if you could help me to determine if this is implementable in Wayland?
>>>>
>>>> Thanks in advance,
>>>>
>>>> Maxim.
>>>>