Axis events to keyboard focus (Re: Input and games.)

[Bill Spitzak]

Todd Showalter wrote:
> On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk <madewokherd at gmail.com> wrote:
> 
>> A compositor could just drop events that aren't over a focused window,
>> and it would solve Todd's problem, unless he's also expecting to be
>> able to scroll things without hovering over them.
> 
>     My problem is that I expect one of two cases:
> 
> 1) all focus follows the pointer (this is what I prefer)
> 
> 2) click to focus
> 
>     I can live with either, though I vastly prefer
> focus-follows-pointer.  The problem in OSX is that it's this broken
> mushing of the two systems together; scroll wheel focus follows the
> pointer, keyboard is click-to-focus.

I agree that is exactly what is wrong on OS/X.

Besides point-to-type and click-to-type there are a zillion other 
possibilities, which are unexplored because current window systems force 
the focus navigation to be part of the shell. An example would be that 
the keyboard focus moves to the pointer window on a mouse-wheel scroll, 
which would actually solve the OS/X problem you describe.

I believe Wayland can allow focus navigation to be the client's 
responsibility. The client can decide whether it is point-to-type or 
click-to-type, and also lots of other possibilities. This is done with 
the following requests:

1. Take keyboard focus. This only works if the client has keyboard or 
pointer focus.

A client that wants click-to-type grabs the keyboard focus on clicks. It 
can also grab it on other events, like the scroll wheel. Also whether 
the "focus click" can push buttons is left for the client to decide.

A client that wants point-to-type grabs the keyboard focus on mouse 
enter, or on movement to some active area.

2. Take pointer focus. This only works in response to a 
keyboard-focus-in, or if they client already has pointer focus. The 
pointer is moved by the shell to point at some location in the surface 
(or to a rectangle provided in the request).

The take-pointer-focus is so that a point-to-type client can respond to 
keyboard focus events the shell produces by putting itself in a 
consistent state where the pointer points at it. The primary purpose is 
so a new window can popup with keyboard focus. Note this is NOT "focus 
stealing" because the shell has to give the client keyboard focus, so 
any solution to focus stealing for click-to-type works for this, too.

3. Raise. Wayland does this already, but it is vitally important that 
surfaces only raise when the client requests it. This allows the client 
to decide to take focus with or without raising.