Client keyboard focus

[Maxim Kartashev]

> So long as there's no limbo state, that will work reliably.

The limbo state is baked into this particular cake.

> Perhaps a non-destructive peek ahead at the native event queue ?

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.

On Sat, Nov 25, 2023 at 7:34 AM Philip Race <philip.race at oracle.com> wrote:

> 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.
> >>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/wakefield-dev/attachments/20231127/9596f6e9/attachment.htm>