how to implement animation in wayland since window move request is not supported?

[Barry Song]

Scott Anderson <scott.anderson at collabora.com> 于2019年5月6日周一 下午1:45写道：
>
> On 6/05/19 1:37 pm, Barry Song wrote:
> > sorry for the ascii text picture can't show well in gmail. the
> > animation is pretty much like
> >   drop-down terminal - Yakuake
> > https://kde.org/applications/system/yakuake/
> >
> > when you push a key, the Yakuake will move out from the top.
> >
> >
> > Barry Song <21cnbao at gmail.com> 于2019年5月6日周一 下午1:31写道：
> >>
> >> Hi Simon,
> >>
> >> Simon Ser <contact at emersion.fr> 于2019年5月6日周一 上午9:54写道：
> >>>
> >>> Hi,
> >>>
> >>> On Monday, May 6, 2019 12:17 AM, Barry Song <21cnbao at gmail.com> wrote:
> >>>> Hi,
> >>>> It seems wayland doesn't support the move() and setGeometry() from
> >>>> clients. No any message is sent from Qt to weston for qWidget.move()
> >>>> or qDialog.move(). So weston has no any idea that clients are
> >>>> requesting to move a window.
> >>>> Under this condition, how could people implement animation of a window?
> >>>>
> >>>> Right now, a software uses a timer to move window, in the callback of
> >>>> the timer, the window is moved a little and the timer is fired again.
> >>>> So the window can move and move, which is generating an animation.
> >>>> This works well in non-wayland platforms. But the move() codes seems
> >>>> to have no any impact under wayland.
> >>>>
> >>>> So do we have some alternative way to implement the animation of a window?
> >>>
> >>> This has been intentionally left out.
> >>>
> >>> Could you explain exactly what is your use-case? What kind of
> >>> application are you working on, what does this dialog contain, what you
> >>> want to do?
> >>
> >> click a button, a window will move out from the top to its position.
> >>
> >> click a button, a window will move out from the right to its position.
> >>
> >> the windows are not shown on screen directly, it is moving out.
> >>
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> Simon Ser
> >>> https://emersion.fr
> >>
> >> -barry
>
> Hi,
>
> This is the kind of feature that would be implemented in the compositor,
> not in the client. As Simon already mentioned, normal clients have know
> knowledge or control of where they are placed.

while I agree this feature should be implemented in compositor, client
still needs to tell compositor which window needs this animation as
not everyone needs it.
how can compositor knows which window needs moving out and which needs
to present directly if there are no any code difference between these
two kinds of windows?
right now, using non-wayland, clients can differentiate by
QDialog D1, D2;

T1 time:
D1.move(x1, y1);
T2 time:
D1.move(x2, y2);
....

D2.show();

Then D1 has animation, but D2 has no.

>
> However, there is an extension protocol called wlr-layer-shell which
> allows clients to anchor itself to the side of the screen (among other
> things) which would work for something like Yakuake, but that is not
> implemented in all compositors.
>
> Scott

-barry