[PATCH weston 08/17] xdg-shell: Further clarify xdg_surface.move semantics

[Jasper St. Pierre]

If there's an application that wants a move indicator, we could
provide a "moving" state, but since the application doesn't get any
feedback about the move, ever, I'm not sure this is useful.

On Thu, Apr 30, 2015 at 7:36 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 7 Apr 2015 18:40:03 -0700
> Bryce Harrington <bryce at osg.samsung.com> wrote:
>
>> On Tue, Apr 07, 2015 at 05:01:23PM +0800, Jonas Ådahl wrote:
>> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
>> > ---
>> >  protocol/xdg-shell.xml | 13 +++++++++++--
>> >  1 file changed, 11 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
>> > index d013803..46775fe 100644
>> > --- a/protocol/xdg-shell.xml
>> > +++ b/protocol/xdg-shell.xml
>> > @@ -233,10 +233,19 @@
>> >     Start an interactive, user-driven move of the surface.
>> >
>> >     This request must be used in response to some sort of user action
>> > -   like a button press, key press, or touch down event.
>> > +   like a button press, key press, or touch down event. The passed
>> > +   serial is used to determine what type of interactive move (touch,
>> > +   pointer, etc) is.
>>
>> ...us used to determine the type of interactive move (e.g. touch,
>> pointer, etc.)
>>
>> >     The server may ignore move requests depending on the state of
>> > -   the surface (e.g. fullscreen or maximized).
>> > +   the surface (e.g. fullscreen or maximized), or if the passed serial
>> > +   is no longer valid.
>> > +
>> > +   If triggered, the surface will loose the focus of the device
>> s/loose/lose/
>>
>> > +   (wl_pointer, wl_touch, etc) used for the move. It is up to the
>> > +   compositor display any indications, such as updating a pointer cursor,
>>
>> ...compositor *to* display... ?
>>
>> And is 'indications' the right word?  I don't understand the meaning of
>> this sentence.
>
> It tries to say that the compositor should visually indicate, that the
> user is now indeed moving the window.
>
>> > +   during the move. There is no guarantee that the device focus will
>> > +   return when the move is completed.
>> >        </description>
>> >        <arg name="seat" type="object" interface="wl_seat" summary="the wl_seat of the user event"/>
>> >        <arg name="serial" type="uint" summary="the serial of the user event"/>
>> > --
>
> This does make me wonder, though. Doing a window move will then switch
> from app cursors to compositor cursors. It also doesn't allow the app
> to show the move-indicators itself, because it doesn't know when the
> move ends? Do these matter? I don't even pretend to be suggesting
> answers here.
>
> Anyway, no reason hold up this patch.
> Acked-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>
> And if this is how it has already been implemented, then this is no
> reason to bump the experimental version either.
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper