[PATCH weston 08/17] xdg-shell: Further clarify xdg_surface.move semantics
Jasper St. Pierre
jstpierre at mecheye.net
Thu Apr 30 09:28:10 PDT 2015
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
>> > + (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.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel