Gamepad focus model (Re: Input and games.)

[Peter Hutterer]

On Wed, May 08, 2013 at 11:46:43AM +0000, Rick Yorgason wrote:
> 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.

if you have more than one application open, you may want the keyboard focus
in a different window than gamepad focus. think of 'taking notes while
playing a game'

from what I understand nothing currently stops the compositor from setting
the gamepad focus to the same surface as the keyboard focus. encoding that
in the protocol however is not a good idea.

Cheers,
   Peter