[weston] xwm: find a seat for all the surface's views

Submitted by Giulio Camuffo on Oct. 4, 2014, 10:58 a.m.

Details

Message ID 1412420313-8295-1-git-send-email-giuliocamuffo@gmail.com
State Accepted
Commit ad7305ad74226c154243f33b59fd441ed2743a2a
Headers show

Not browsing as part of any series.

Commit Message

Giulio Camuffo Oct. 4, 2014, 10:58 a.m.
This allows to move or resize a xwayland client by acting on all
its views.
---
 xwayland/window-manager.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Patch hide | download patch | download mbox

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 4e91f9d..a283a3c 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1214,8 +1214,8 @@  weston_wm_pick_seat_for_window(struct weston_wm_window *window)
 
 	seat = NULL;
 	wl_list_for_each(s, &wm->server->compositor->seat_list, link) {
-		if (s->pointer != NULL &&
-		    s->pointer->focus == window->view &&
+		if (s->pointer != NULL && s->pointer->focus &&
+		    s->pointer->focus->surface == window->surface &&
 		    s->pointer->button_count > 0 &&
 		    (seat == NULL ||
 		     s->pointer->grab_serial -
@@ -1248,7 +1248,8 @@  weston_wm_window_handle_moveresize(struct weston_wm_window *window,
 		&wm->server->compositor->shell_interface;
 
 	if (seat == NULL || seat->pointer->button_count != 1
-	    || !window->view || seat->pointer->focus != window->view)
+	    || !seat->pointer->focus
+	    || seat->pointer->focus->surface != window->surface)
 		return;
 
 	detail = client_message->data.data32[2];

Comments

On Sat,  4 Oct 2014 13:58:33 +0300
Giulio Camuffo <giuliocamuffo@gmail.com> wrote:

> This allows to move or resize a xwayland client by acting on all
> its views.

Hmm, is this a good thing? What use cases you had in mind?

Shouldn't there be a difference between move/resizeable views and other
views? Like if you have an additional view in a pager or the alt+tab
list, that shouldn't be resizable and it might not want to be
interactive (input-capable) at all.

What's the idea here? Not just for Xwayland windows but all of them.

I think we have no distinction between interactive and non-interactive
views currently, so we just handle it through grabs, am I right?

So, this patch is simply to make the Xwayland windows behave the same
as native windows?


Thanks,
pq


> ---
>  xwayland/window-manager.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 4e91f9d..a283a3c 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1214,8 +1214,8 @@ weston_wm_pick_seat_for_window(struct weston_wm_window *window)
>  
>  	seat = NULL;
>  	wl_list_for_each(s, &wm->server->compositor->seat_list, link) {
> -		if (s->pointer != NULL &&
> -		    s->pointer->focus == window->view &&
> +		if (s->pointer != NULL && s->pointer->focus &&
> +		    s->pointer->focus->surface == window->surface &&
>  		    s->pointer->button_count > 0 &&
>  		    (seat == NULL ||
>  		     s->pointer->grab_serial -
> @@ -1248,7 +1248,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window,
>  		&wm->server->compositor->shell_interface;
>  
>  	if (seat == NULL || seat->pointer->button_count != 1
> -	    || !window->view || seat->pointer->focus != window->view)
> +	    || !seat->pointer->focus
> +	    || seat->pointer->focus->surface != window->surface)
>  		return;
>  
>  	detail = client_message->data.data32[2];
2014-11-12 13:25 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
> On Sat,  4 Oct 2014 13:58:33 +0300
> Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
>
>> This allows to move or resize a xwayland client by acting on all
>> its views.
>
> Hmm, is this a good thing? What use cases you had in mind?

I have two views for the same surface, and they are both user
interactable and indistinguishable from each other. As of now, only
one can be moved or resized, for no apparent reason.

>
> Shouldn't there be a difference between move/resizeable views and other
> views? Like if you have an additional view in a pager or the alt+tab
> list, that shouldn't be resizable and it might not want to be
> interactive (input-capable) at all.

Yeah, but that can be done in the shell, by looking at the view that
is under the pointer. If that view is not supposed to be used to
resize the surface, ignore the resize request.

>
> What's the idea here? Not just for Xwayland windows but all of them.
>
> I think we have no distinction between interactive and non-interactive
> views currently, so we just handle it through grabs, am I right?
>
> So, this patch is simply to make the Xwayland windows behave the same
> as native windows?

Yes, basically, or more similar.

>
>
> Thanks,
> pq
>
>
>> ---
>>  xwayland/window-manager.c | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>> index 4e91f9d..a283a3c 100644
>> --- a/xwayland/window-manager.c
>> +++ b/xwayland/window-manager.c
>> @@ -1214,8 +1214,8 @@ weston_wm_pick_seat_for_window(struct weston_wm_window *window)
>>
>>       seat = NULL;
>>       wl_list_for_each(s, &wm->server->compositor->seat_list, link) {
>> -             if (s->pointer != NULL &&
>> -                 s->pointer->focus == window->view &&
>> +             if (s->pointer != NULL && s->pointer->focus &&
>> +                 s->pointer->focus->surface == window->surface &&
>>                   s->pointer->button_count > 0 &&
>>                   (seat == NULL ||
>>                    s->pointer->grab_serial -
>> @@ -1248,7 +1248,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window,
>>               &wm->server->compositor->shell_interface;
>>
>>       if (seat == NULL || seat->pointer->button_count != 1
>> -         || !window->view || seat->pointer->focus != window->view)
>> +         || !seat->pointer->focus
>> +         || seat->pointer->focus->surface != window->surface)
>>               return;
>>
>>       detail = client_message->data.data32[2];
>
On Wed, 12 Nov 2014 13:32:59 +0200
Giulio Camuffo <giuliocamuffo@gmail.com> wrote:

> 2014-11-12 13:25 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
> > On Sat,  4 Oct 2014 13:58:33 +0300
> > Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
> >
> >> This allows to move or resize a xwayland client by acting on all
> >> its views.
> >
> > Hmm, is this a good thing? What use cases you had in mind?
> 
> I have two views for the same surface, and they are both user
> interactable and indistinguishable from each other. As of now, only
> one can be moved or resized, for no apparent reason.
> 
> >
> > Shouldn't there be a difference between move/resizeable views and other
> > views? Like if you have an additional view in a pager or the alt+tab
> > list, that shouldn't be resizable and it might not want to be
> > interactive (input-capable) at all.
> 
> Yeah, but that can be done in the shell, by looking at the view that
> is under the pointer. If that view is not supposed to be used to
> resize the surface, ignore the resize request.

Only if you actually have a grab, right? Otherwise the core input event
machinery will relay input events to the surface. But yes, we always(?)
have a custom grab in those situations.

> >
> > What's the idea here? Not just for Xwayland windows but all of them.
> >
> > I think we have no distinction between interactive and non-interactive
> > views currently, so we just handle it through grabs, am I right?
> >
> > So, this patch is simply to make the Xwayland windows behave the same
> > as native windows?
> 
> Yes, basically, or more similar.

Alright, pushed.


Thanks,
pq


> >> ---
> >>  xwayland/window-manager.c | 7 ++++---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> >> index 4e91f9d..a283a3c 100644
> >> --- a/xwayland/window-manager.c
> >> +++ b/xwayland/window-manager.c
> >> @@ -1214,8 +1214,8 @@ weston_wm_pick_seat_for_window(struct weston_wm_window *window)
> >>
> >>       seat = NULL;
> >>       wl_list_for_each(s, &wm->server->compositor->seat_list, link) {
> >> -             if (s->pointer != NULL &&
> >> -                 s->pointer->focus == window->view &&
> >> +             if (s->pointer != NULL && s->pointer->focus &&
> >> +                 s->pointer->focus->surface == window->surface &&
> >>                   s->pointer->button_count > 0 &&
> >>                   (seat == NULL ||
> >>                    s->pointer->grab_serial -
> >> @@ -1248,7 +1248,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window,
> >>               &wm->server->compositor->shell_interface;
> >>
> >>       if (seat == NULL || seat->pointer->button_count != 1
> >> -         || !window->view || seat->pointer->focus != window->view)
> >> +         || !seat->pointer->focus
> >> +         || seat->pointer->focus->surface != window->surface)
> >>               return;
> >>
> >>       detail = client_message->data.data32[2];
> >
2014-11-18 15:05 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
> On Wed, 12 Nov 2014 13:32:59 +0200
> Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
>
>> 2014-11-12 13:25 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
>> > On Sat,  4 Oct 2014 13:58:33 +0300
>> > Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
>> >
>> >> This allows to move or resize a xwayland client by acting on all
>> >> its views.
>> >
>> > Hmm, is this a good thing? What use cases you had in mind?
>>
>> I have two views for the same surface, and they are both user
>> interactable and indistinguishable from each other. As of now, only
>> one can be moved or resized, for no apparent reason.
>>
>> >
>> > Shouldn't there be a difference between move/resizeable views and other
>> > views? Like if you have an additional view in a pager or the alt+tab
>> > list, that shouldn't be resizable and it might not want to be
>> > interactive (input-capable) at all.
>>
>> Yeah, but that can be done in the shell, by looking at the view that
>> is under the pointer. If that view is not supposed to be used to
>> resize the surface, ignore the resize request.
>
> Only if you actually have a grab, right? Otherwise the core input event
> machinery will relay input events to the surface. But yes, we always(?)
> have a custom grab in those situations.

No need to have a custom grab. The weston_shell_interface resize or
move hooks are no different to wl_shell_surface's. When called it just
needs to check 'seat->pointer->focus'. If 'focus' is not supposed to
be resized, bail.


--
Giulio

>
>> >
>> > What's the idea here? Not just for Xwayland windows but all of them.
>> >
>> > I think we have no distinction between interactive and non-interactive
>> > views currently, so we just handle it through grabs, am I right?
>> >
>> > So, this patch is simply to make the Xwayland windows behave the same
>> > as native windows?
>>
>> Yes, basically, or more similar.
>
> Alright, pushed.
>
>
> Thanks,
> pq
>
>
>> >> ---
>> >>  xwayland/window-manager.c | 7 ++++---
>> >>  1 file changed, 4 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>> >> index 4e91f9d..a283a3c 100644
>> >> --- a/xwayland/window-manager.c
>> >> +++ b/xwayland/window-manager.c
>> >> @@ -1214,8 +1214,8 @@ weston_wm_pick_seat_for_window(struct weston_wm_window *window)
>> >>
>> >>       seat = NULL;
>> >>       wl_list_for_each(s, &wm->server->compositor->seat_list, link) {
>> >> -             if (s->pointer != NULL &&
>> >> -                 s->pointer->focus == window->view &&
>> >> +             if (s->pointer != NULL && s->pointer->focus &&
>> >> +                 s->pointer->focus->surface == window->surface &&
>> >>                   s->pointer->button_count > 0 &&
>> >>                   (seat == NULL ||
>> >>                    s->pointer->grab_serial -
>> >> @@ -1248,7 +1248,8 @@ weston_wm_window_handle_moveresize(struct weston_wm_window *window,
>> >>               &wm->server->compositor->shell_interface;
>> >>
>> >>       if (seat == NULL || seat->pointer->button_count != 1
>> >> -         || !window->view || seat->pointer->focus != window->view)
>> >> +         || !seat->pointer->focus
>> >> +         || seat->pointer->focus->surface != window->surface)
>> >>               return;
>> >>
>> >>       detail = client_message->data.data32[2];
>> >
>
On Tue, 18 Nov 2014 15:17:55 +0200
Giulio Camuffo <giuliocamuffo@gmail.com> wrote:

> 2014-11-18 15:05 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
> > On Wed, 12 Nov 2014 13:32:59 +0200
> > Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
> >
> >> 2014-11-12 13:25 GMT+02:00 Pekka Paalanen <ppaalanen@gmail.com>:
> >> > On Sat,  4 Oct 2014 13:58:33 +0300
> >> > Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
> >> >
> >> >> This allows to move or resize a xwayland client by acting on all
> >> >> its views.
> >> >
> >> > Hmm, is this a good thing? What use cases you had in mind?
> >>
> >> I have two views for the same surface, and they are both user
> >> interactable and indistinguishable from each other. As of now, only
> >> one can be moved or resized, for no apparent reason.
> >>
> >> >
> >> > Shouldn't there be a difference between move/resizeable views and other
> >> > views? Like if you have an additional view in a pager or the alt+tab
> >> > list, that shouldn't be resizable and it might not want to be
> >> > interactive (input-capable) at all.
> >>
> >> Yeah, but that can be done in the shell, by looking at the view that
> >> is under the pointer. If that view is not supposed to be used to
> >> resize the surface, ignore the resize request.
> >
> > Only if you actually have a grab, right? Otherwise the core input event
> > machinery will relay input events to the surface. But yes, we always(?)
> > have a custom grab in those situations.
> 
> No need to have a custom grab. The weston_shell_interface resize or
> move hooks are no different to wl_shell_surface's. When called it just
> needs to check 'seat->pointer->focus'. If 'focus' is not supposed to
> be resized, bail.

Hmm, but I am talking about all the normal input events, nothing to do
with resize or move. Like if I click a window in some preview, I don't
want that click to go through to the client. *That* I think is
prevented with grabs, but if you implement something like a pager with
live views, there is no grab to prevent that.

weston_view does not yet have a "do not focus me" flag, I think. I
suppose we will fix that if someone wants to do something like a
pager. :-)

Nevermind, I'm just learning how stuff works atm.


Thanks,
pq