Re: how to implement animation in wayland since window move request is not supported?
Scott Anderson 于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 <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > >> > >> Hi Simon, > >> > >> Simon Ser 于2019年5月6日周一 上午9:54写道： > >>> > >>> Hi, > >>> > >>> On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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. > > 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. it seems set_anchor() can set window to a corner, but it doesn't have the animation according to the below? Requests that the compositor anchor the surface to the specified edges and corners. If two orthogonal edges are specified (e.g. 'top' and 'left'), then the anchor point will be the intersection of the edges (e.g. the top left corner of the output); otherwise the anchor point will be centered on that edge, or in the center if none is specified. Anchor is double-buffered, see wl_surface.commit. > > Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
Scott Anderson 于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 <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > >> > >> Hi Simon, > >> > >> Simon Ser 于2019年5月6日周一 上午9:54写道： > >>> > >>> Hi, > >>> > >>> On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
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 <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： Hi Simon, Simon Ser 于2019年5月6日周一 上午9:54写道： Hi, On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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. 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
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 <21cn...@gmail.com> 于2019年5月6日周一 下午1:31写道： > > Hi Simon, > > Simon Ser 于2019年5月6日周一 上午9:54写道： > > > > Hi, > > > > On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to implement animation in wayland since window move request is not supported?
Hi Simon, Simon Ser 于2019年5月6日周一 上午9:54写道： > > Hi, > > On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wayland-protocols scope and governance
Here's an updated governance document for everyone to consider. Changes from the first version: - Use wayland-devel instead of a dedicated mailing list - Use Gitlab for reviewing new protocols - Extend discussion period for governance amendments from 30 days to 60 - Permit either 1 or 2 points of contact for a wayland-protocols member - Clarify who's affected by the cool-down period after a failed membership removal vote I chose not to change the wording of the xdg namespace definition, despite Daniel's objection. I couldn't come up with a wording that I think would make everyone happy - feedback welcome. Under Daniel's proposed wording of "catch-all window management", a case is easily made for wlr-foreign-toplevel-management: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml I expect this would be controversial. Or perhaps it wouldn't be, and would fit into this namespace, but would just be NACK'd by some folks. Depends on how strongly integrated desktop folks want to gatekeep the XDG namespace. Thoughts? wayland-protocols governance This document governs the maintenance of wayland-protocols and serves to outline the broader process for standardization of protocol extensions in the Wayland ecosystem. 1. Membership Membership in wayland-protocols is offered to stakeholders in the Wayland ecosystem who have an interest in participating in protocol extension standardization. 1.1. Membership requirements a. Membership is extended to projects, rather than individuals. b. Members represent general-purpose projects with a stake in multiple Wayland protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose applications with a stake in only one or two. c. Each project must provide one or two named individuals as points-of-contact for that project who can be reached to discuss protocol-related matters. 1.2. Becoming a member a. New members who meet the criteria outlined in 1.1 are established by invitation from an existing member. Projects hoping to join should reach out to an existing member asking for this invitation. b. New members shall write to the wayland-devel mailing list stating their intention of joining and their sponsor. c. The sponsor shall respond acknowledging their sponsorship of the membership. d. A 14 day discussion period for comments from wayland-protocols members will be held. e. At the conclusion of the discussion period, the new membership is established unless their application was NACKed by a 1/2 majority of existing members. 1.3. Ceasing membership a. A member may step down by writing their intention to do so to the wayland-devel mailing list. b. A removal vote may be called for by an existing member by posting to the wayland-devel mailing list. This begins a 14 day voting & discussion period. c. At the conclusion of the voting period, the member is removed if the votes total 2/3rds of members. d. Removed members are not eligible to apply for membership again for a period of 1 year. e. Following a failed vote, the member who called for the vote cannot call for a re-vote or propose any other removal for 90 days. 2. Protocols 2.1. Protocol namespaces a. Namespaces are implemented in practice by prefixing each interface name in a protocol definition (XML) with the namespace name, and an underscore (e.g. "xdg_wm_base"). b. Protocols in a namespace may optionally use the namespace followed by a dash in the name (e.g. "xdg-shell"). c. The "xdg" namespace is established for protocols useful for implementing desktop-like systems. d. The "wp" namespace is established for protocols generally useful to Wayland implementations (i.e. "plumbing" protocols). e. The "ext" namespace is established as a general catch-all for protocols that fit into no other namespace. 2.2. Protocol inclusion requirements a. All protocols found in the "xdg" and "wp" namespaces at the time of writing are grandfathered into their respective namespace without further discussion. b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if ACKed by at least 3 members. c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if if NACKed by any member. d. Protocols in the "xdg" and "wp" namespaces must have at least one open-source client implementation & two open-source server implementations to be eligible for inclusion. e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by at least one member. f. Protocols in the "ext" namespace must have at least one open-source client & one open-source server implementation to be eligible for inclusion.
Re: how to implement animation in wayland since window move request is not supported?
Hi, On Monday, May 6, 2019 12:17 AM, Barry Song <21cn...@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? Thanks, -- Simon Ser https://emersion.fr ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
how to implement animation in wayland since window move request is not supported?
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? Thanks barry ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Using libweston with GTK/GDK
On Fri, 2019-05-03 at 11:02 +0100, adlo wrote: > > On 3 May 2019, at 10:20, Pekka Paalanen > > wrote: > > > > your Makefile.am needs the rules to generate the headers and .c > > files. > > > > I tried copying an edited Makefile.am from the wayland-protocols git > repository, but it complained about GNU-isms. Is there anything else > I need to do other than just specifying the location of the .xml > files? It's OK, I've managed to do it, like this: protocol/xyz-client-protocol.h : $(top_srcdir)/protocol/xyz.xml $(AM_V_GEN) $(wayland_scanner) client-header $(top_srcdir)/protocol/xyz.xml $(top_srcdir)/protocol/xyz-client- protocol.h Regards adlo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
