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

[Pekka Paalanen]

On Fri, 21 Dec 2012 14:04:03 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> The shell needs to redirect some actions to the parent surface, when
> they originally target a sub-surface. This patch implements the
> following:
> - When the activation binding (left button click) targets a sub-surface,
>   activate the parent surface instead. This also means, that a keyboard
>   focus should never be on a sub-surface, but pointer (and touch) foci
>   can.
> - Move, resize, and rotate bindings always target the parent surface.
> - Opacity (full-surface alpha) binding targets the parent surface. This
>   is broken, because it should change the opacity of the whole compound
>   window, which is difficult to implement in the renderer.
> 
> workspace_manager_move_surface(): is it expected and legal for this to
> be called for sub-surfaces?
> 
> take_surface_to_workspace_by_seat(): I guess this really doesn't need
> the weston_surface_get_parent call, since keyboard focus is supposed to
> never be on a sub-surface.
> 
> move_surface_to_workspace(): like above, should be ok, as keyboard focus
> is not a sub-surface.
> ---
>  src/compositor.c |   13 +++++++++++++
>  src/compositor.h |    3 +++
>  src/shell.c      |    9 +++++++++
>  3 files changed, 25 insertions(+), 0 deletions(-)
> 
...
> diff --git a/src/shell.c b/src/shell.c
> index fe9c55e..cf2edca 100644
> --- a/src/shell.c
> +++ b/src/shell.c
...
> @@ -2703,6 +2711,7 @@ click_to_activate_binding(struct wl_seat *seat, uint32_t time, uint32_t button,
>  	struct weston_surface *upper;
>  
>  	focus = (struct weston_surface *) seat->pointer->focus;
> +	focus = weston_surface_get_parent(focus);
>  	if (!focus)
>  		return;
>  

This hunk is actually not what I meant.

My idea was to do nothing special wrt. input, but this is a special
case. Instead, the shell should just activate the sub-surface as is, and
give keyboard focus to the sub-surface.

This means toolkits will need a fix at least for the "window is active"
handling, since an active sub-surface means the whole window is active.
Toolkits also need to handle the keyboard events coming to sub-surfaces
as coming to the window as a whole.

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, just like whether
click raises or not.

- pq