Gamepad focus model (Re: Input and games.)

[Rick Yorgason]

Rick Yorgason <rick at ...> writes:
> > Having the two controllers paired doesn't solve 3.  There are a lot of UI
> > problems with having two pointers running around the screen that share a
> > focus.  Let's say they're one of those crazy users that like sloppy-
> > focus.  What happens when the two cursors are on different windows?  Does
> > the primary cursor over-ride?  Does the secondary cursor work in windows
> > that aren't focused?  Even if you have click-to-focus, you still have
> > problems with the two cursors fighting.  What happens if they both try to
> > do a drag-and-drop?  The only solution to this is probably to make the
> > secondary pointer inert in windows that aren't focussed.  That said, I'm
> > not sure if that 100% fixes it either.
> 
> I was thinking that a desktop environment would probably only have one
> cursor. In other words, if any wl_seats are sharing focus, most apps would
> treat them as aggregate, and it would only be more specialized apps (like
> games) that might want to separate them.

In thinking more about this some more, I don't even think these seats need
to be aggregated. A second-class wl_seat would just mean "This seat is
intended to be used at the application level rather than the compositor
level, and it will send enter/leave events to the same surfaces as its parent."

In other words, if you move the mouse attached to a second-class wl_seat,
the compositor completely ignores that motion.

Now, when you read what I wrote about how enter/leave events get propagated
to second-class wl_seats, you probably thought "Wait, enter/leave events are
produced by wl_pointer, wl_keyboard, and maybe wl_gamepad. Are you
suggesting *all* of those get propagated?"

Well, I don't think it makes sense to propagate wl_pointer::enter/leave, and
this leads me to what I believe is an unfortunate design choice in the
current protocol, which is that wl_keyboard::enter/leave doesn't make much
sense. It should really be wl_seat::enter/leave.

wl_pointer::enter/leave makes sense because pointers are special. They can
freely move outside of surfaces, and can affect things in unfocused
applications. But the keyboard focus is pretty much identical to the
application focus: in a typical compositor, when an application gets
keyboard focus, that application's title bar will light up.

Currently it would make perfect sense for wl_gamepad to use wl_keyboard's
focus except... what do you do if there is no keyboard? This would have been
an easier problem to solve if we could just say that wl_keyboard and
wl_gamepad both use wl_seat's focus.

-Rick-