[PATCH weston 4/5] shell: keyboard focus with sub-surfaces

[Bill Spitzak]

Pekka Paalanen wrote:

> If the client wants to assign keyboard focus to a different
> (sub-)surface than where the compositor is offering it, that is left
> for a future keyboard focus negotiation protocol,

As long as the key events are delivered to *any* client surface then the 
client can pretend that any of the surfaces has keyboard focus.

I really think the proper solution is that wayland lets a client "grab" 
the keyboard focus to any surface at any time. The shell can put some 
restrictions on this such as making sure the mouse is currently inside 
one of the client's windows, in order to ignore hostile clients. But 
wayland *never* changes what surface gets keyboard events except by 
client request.

Alt-tab style shortcuts just cause an offer of keyboard to the client, 
the client must respond with a grab if the focus really changes.

This is enormously simpler than trying to describe exactly what style 
and area of clicks deliver keyboard focus. A client that does not grab 
keyboard focus just because a user wants to hit a button, while still 
allowing keyboard focus in other cases, would be a pretty nice 
improvement in usability. Right now things like media players go through 
some pretty strange ui choices to work around this.

> just like whether
> click raises or not.

Yes. The ONLY way a window should ever be raised is if the client does a 
"raise" request. This moves all the decisions about what a click means 
to the client. In particular it makes the "drag and drop problem" 
trivial to solve. It also means we can have clients that know they are 
useful when partially buried and not raise on some clicks, which would 
be an AMAZING improvement of usabilty we have been lacking for 25 years 
now ever since Windows broke this and X copied it.