Re: [PATCH] Add the KDE server decoration protocol
On Mon, Oct 30, 2017 at 5:03 AM, Jonas Ådahl wrote: > On Fri, Oct 27, 2017 at 01:13:15PM +0100, David Edmundson wrote: > > The server decoration protocol negotiates between the client and server > > whether the client should default to drawing window decorations, and > > informs the compositor what the client is doing. > > > > This is useful not just for a compostior that is doing decorations > > itself, but much more importantly for a toolkit, such as Qt which > > primarily targets embedded and IVI applications, not to have to modify > > clients > > to add a header bar which makes them usable on a desktop compositor. > > > > This file is currently copied in multiple places across GTK, Sway as well > > as being needed in both Qt and KDE. We should have this in a shared > > place. > > I think that this functionality is in scope for wayland-protocols, but > wayland-protocols was AFAIK never meant as a distribution of arbitrary > external protocols. In the beginning, a major reason why it was created > at all was because wayland.xml was getting too large and it was too > inconvenient to wait for wayland releases for adding a new protocol or > protocol version would we instead add new XML files to the wayland repo. > > I'd expect protocols that aim to be included here to be willing to go > through protocol review and adhere to the conventions we have set up. > I have read through the protocol and will provide feedback as if the > protocol aims to follow the conventions we have in place. > Sounds reasonable. I understand you don't want to have a generic dumping ground. Thanks for the very thorough review. > > > --- > > unstable/server-decoration/server-decoration.xml | 94 > > > > 1 file changed, 94 insertions(+) > > create mode 100644 unstable/server-decoration/server-decoration.xml > > > > diff --git a/unstable/server-decoration/server-decoration.xml > > b/unstable/server-decoration/server-decoration.xml > > new file mode 100644 > > index 000..8bc106c > > --- /dev/null > > +++ b/unstable/server-decoration/server-decoration.xml > > @@ -0,0 +1,94 @@ > > + > > + > > + > > + version="1"> > > I believe a protocol related to window decorations belong in the "xdg" > family of protocols, extending 'xdg_wm_base'. For example > 'xdg_wm_window_decorations' could be the name of a window decoration > extension to xdg_wm_base (that is the main interface of xdg_shell). > Sure, my initial intention was to share the spec that's currently being used, rather than define something "xdg official". Long term the latter is probably better even if it is going to be more work for all involved. > > + > > +This interface allows to coordinate whether the server should > > create > > +a server-side window decoration around a wl_surface > representing a > > +shell surface (wl_shell_surface or similar). By announcing > support > > +for this interface the server indicates that it supports server > > +side decorations. > > + > > + > > + > > +When a client creates a server-side decoration object it > > indicates > > +that it supports the protocol. The client is supposed to > tell > > the > > +server whether it wants server-side decorations or will > provide > > +client-side decorations. > > + > > +If the client does not create a server-side decoration > object > > for > > +a surface the server interprets this as lack of support for > > this > > +protocol and considers it as client-side decorated. > > Nevertheless a > > +client-side decorated surface should use this protocol to > > indicate > > +to the server that it does not want a server-side deco. > > What is the purpose of a client not supporting server side decorations > to create this object anyway? I assume functionality wise it shouldn't > make any difference right? > It shouldn't. > > > + > > + > interface="org_kde_kwin_server_decoration"/> > > + > > + > > + > > + > > + > > Why would a popup surface create a window decoration object at all? It > seems pointless. I might be missing something but it seems to only make > any sense to only deal with toplevels. A request creating the window > decoration object could for example require that
Re: [PATCH wayland-protocols v3 01/17] Add xdg-shell to stable/
Looks good to me! Reviewed-by: David Edmundson ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
Reviewed-by: David Edmundson ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland-protocols] unstable: add protocol to give focus to a foreign surface
This protocol is to address the following use case. A user clicks on a URL link in an IRC chat and a web browser opens. We want an existing browser window to raise or if it's a newly spawned application to claim focus on startup. Naturally we also don't want any arbitrary client to be able to raise themselves arbitrarily. The protocol is a combination of xdg-foreign and some very simplified aspects of X's startup-notification. In the example above, the chat client gets a token from the compositor and passes it to the browser using: - an environment variable for newly spawned apps - platofrm-hints in the org.freedesktop.Application interface - some hint in the relevant xdg-portal interface - any custom mechanism The browser then requests a raise of a top-level using this token. (Exact common mechanisms should probably be defined, but maybe not in this document) The exporter is virtually identical to xdg-foreign's exporter, but we can't re-use directly it as it's important that clients know what the exported handle could be used for. Extending xdg-foreign would be a viable solution, but the lifespan of handles needs to be different.. Honouring the activation request is entirely up to the compositor which can have whatever advanced focus rules it wants. Draft proposal below: --- This protocol allows a top level to give up focus and pass it to a specific other client. An example use case would be a chat client opening a link in a browser, that should raise an existing window or start the newly opened window with focus. The application releasing focus (focus_exported) fetches a handle from the compositor and then passes it to another client using a third party mechanism. The receiving application can use this handle to request focus from the compositor. A global interface used for exporting surfaces that can later be imported using xdg_importer. Notify the compositor that the xdg_exporter object will no longer be used. It is an error to export a focus that is not mapped. Inform the compositor that this focus_exported object is no longer used. The handle remains valid and can still be used by the compositor. This is to allow windows to close themselves after activating another application. The handle event contains the unique handle of this exported surface reference. It may be shared with any client, which then can use it to import the surface by calling zxdg_activator_v1.activate_toplevel. A handle may be used only once. A global interface used for importing surfaces exported by xdg_focus_exporter. With this interface, a client can create a reference to a surface of another client. Notify the compositor that the xdg_activator object will no longer be used. Request to the compositor that this surface should claim focus from the exported handle. This request can be sent at any time to raise an alread mapped window or before the window is mapped to request focus when the window is first configured. At this point the handle is invalidated and cannot be used again. The compositor is free to ignore this request. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] unstable: add protocol to give focus to a foreign surface
On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault wrote: > I'm not sure why an activiation request has to jump through these > surface export hoops first. > I think it's important to distinguish focus/raising from urgent/needs attention hints. I'm only interested in focus/raising. Historically on X there was a problem of windows claiming focus randomly and unexpectedly; especially with things like random password prompts when things loaded. Kwin certainly has an insane amount of focus protection logic and rules. If you're not going to give focus to any client that asks, it means you need some way to separate a client asking for attention and the currently focused client being ok with it. I see where you're going with this, though: an atomic and secure way of > transferring focus to another application. This looks like an attempt to > express something like intents on Wayland. > > I think xdg-portal is becoming the closest thing we have to intents in the desktop space. Currently you'll see a "string: window" argument in most the methods which ties in with the current xdg_foreign. I basically want that, but I don't always want a parent/child relationship. > > Perhaps designing an out-of-band intents system first, then having it > express some kind of handle, which can then be referred to from Wayland > for the purpose of securely transferring focus, would be a better > approach. It's hard to design a good Wayland protocol against the > ephemeral "it may exist eventually" out-of-band negotiation process. > Right, I phrased that very badly. There is a pre-existing out of band system for X startup notifications that is defined in the places I said. This exists and is used certainly in Qt/Kde and GTK code (weirdly gtk wayland also uses desktop_startup_id ...) X startups are a bit more involved as clients inform the system what exact process they're starting with atoms for the icon and a name, so the taskbar can pre-empt things and do startup feedback then pass an ID of this startup window to the other client. But ultimately there's a string ID which gets passes between windows out of band, and kwin on X uses that as a major clue of if a client should get raised. Effectively all that needs defining is new variable names. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] unstable: add protocol to give focus to a foreign surface
>Hm. If you wanted to, you could make this explicit by requiring an event >serial in the export_surface request rather than the wl_surface. Certainly an option. Though I'm not sure we have a use case of needing to limit a client releasing its focus? >Does this interface need to exist? It doesn't /need/ to, but I need to be able to export a handle multiple times and it's nice in the client to be able to match up requests with the reply. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] xdg-shell: Add support for synchronized popup moving
set_reactive Everything about this part makes sense. +1 - move request + moved Concept of having explicit updating makes sense. Might be worth considering calling it xdg_popup.reposition as xdg_toplevel.move is very different Would it be valid to re-use the same positioner object each time? Could we repurpose wl_display.sync as an alternative for the moved signal? Simply for code re-use. It slightly reverses the logic, but after your callback a client knows it definitely has the latest configure event for your move request. - sync_with_popup In example A --> xdg_toplevel.configure(200, 600) --> xdg_popup_surface.configure(3) <-- xdg_popup_surface.ack_configure(3) <-- xdg_popup_surface.sync_with_popup(xdg_popup) Should this be xdg_toplevel_surface? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
> + > + > + > + > + Passing a serial also needs a wl_seat object to relate the two ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
Thanks for working on this, activation is something key that we are sorely missing. If we want a complete 1:1 port of the X11 protocol, this certainly technically fine, other than my one minor comment. I dislike the X11 spec, so it's not my preference moving forward. The main thing I dislike is that it requires the surface releasing focus to know what it will be launching. Especially with flatpal + xdg portal we're increasingly going to be to want to pass focus without knowing to whom. Similarly, dbus activation on a common name such as filemanager1 could be to any app. The other thing I've had a problem with is that historically we have a lot of problems with apps not clearing their startup notifications. This was especially true of apps that immediately dock to the status icon, something this spec would have a problem with, unless we allow nulls to the acknowledge request. IMHO we can get something cleaner if we treat it as two independent problems. * Passing focus * Startup notifications One is conceptually passing data from surface-> surface The other is passing data app -> the shell There's some overlap, but not a lot. Personally I would also like to see set_activation_token(string, seat, serial) and activate(string) be methods on xdg_toplevel, partly because they're so integral to everyday operation, partly because it's the only surface type we want to activate. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_output physical size when unknown
I need to patch either a client toolkit or a compositor and I'm not sure which. There are some cases where we don't have a physical size for an output. For example projectors or headless virtual machines, Currently we (kwin) can send a physical size of 0,0 which is causing some client issues which are calculating us as having 0 dots per inch and doing something wrong. Should: a) Compositors should generate something fake but sensible b) Clients should handle this case I think there's a strong argument for either. What are others doing? David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: appId title / Iconic dock launchers
This may be a question for the general xdg mailing list. >All of the above are exposed as $XDG_DATA_DIRS whatever application you pin depends on the priority the lookup is done, very often it will not pin the application it should! I wouldn't remotely call it "broken by design". There are legitimate cases for overriding it's relatively common to override firefox.desktop or whatever into your local paths so that you can meddle with the environment. But semantically those do want to refer to the same thing and explicitly not update every launcher. Ultimately it comes down to if things should have different IDs they should have different IDs. That's a client problem, not a wayland problem. In KDE3 and KDE4 times we used to have an argument we passed in to applications where we would pass the .desktop file name as an argument which would then be used for the X11 startup notifications. I think that's what would solve your problem best. >I imagine it could be possible additionally to appId and title to expose maybe >the path to the actual binary? You do have the pid from the client. From that you have the path to the "actual binary" already. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Implemented lower window when middle click on titlebar in gtk/mutter
For non-Gnome people, what does "lower" mean in this context? David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Current state of Window Decorations
>would you typically have one surface for the decorations and an embedded sub-surface for the content area? For optimisation reasons you would probably do 5 subsurfaces. top,left,right,bottom, main contents. And that would allow the mixing of GL and raster as they are different surfaces. I believe Qt intend to go this way for their client side decoration fallback. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Compositor handoffs: Switching clients between compositors
Hi all, I have been working on a method of "Compositor handoffs"--allowing clients to switch between compositors at runtime--and I wanted to share my progress with everyone and gather some feedback. # Overview The design is very simple at it's core. A client knows everything about the state of it's windows and still owns all appropriate memory. In the event of a compositor exit, the client should be able to just send everything again like it's a brand new client. I have successfully ported: Qt, SDL and XWayland to do this, and they have worked with practically every application using those toolkits that I have thrown at it. The primary goal of this is to handle a compositor crash. Whilst rare, it happens to some extent to all of the desktops and with wayland still being such a dynamic landscape and taking on more and more responsibilities for security reasons this isn't something that will end anytime soon. We want to make sure we don't have a path where users can lose data. Long term this could solve other future goals, like switching between compositors across graphic cards, supporting CRIU (checkpoint restore in userspace) for GUI applications for mobile, or dynamically switching between the active compositor and waypipe. All of which will be really interesting new features. It also makes the developer experience a billion times better, as I am no longer needing to log out to actually test changes, or only test in contrived nested situations. # Slightly more detail ## The compositor The only change we needed to make in the compositor was making our public facing socket (i.e /var/run/.../wayland-0) persist on the file system. We run a small helper that creates the socket then spawns our real compositor. If our compositor crashes, we re-use the same socket. Clients still receive the same error about being disconnected, but there are no races should a client try to reconnect whilst a compositor is starting. systemd's socket activation would also be an option here, though we ended up writing something custom. ## Toolkit changes Whilst this appears as an invasive thing to retroactively insert, it turns out to be relatively unintrusive and small. Most of the tasks we need to do involve functions that already exist anyway. We need to: - reset every wl_output (which can happen at runtime already) - reset input devices (which can happen at runtime already) - reset our data devices (which can get cancelled at runtime already) - reset our wl_surface/xdg_shell objects - send new contents (which happens already) So for the most part we're just hooking into existing code. ## SDL: https://github.com/davidedmundson/SDL/ branch reconnect With the above patchset if the compositor crashes, all SDL apps will reconnect. This was tested against everything in SDL's test directory as well as obviously supertuxkart, the most important client on all our machines. This is a good example to look at to see the extent of toolkit changes, the changes come in at around 200 lines, and the vast majority of that is in the cursor code. ## Qt (Qt5 version) https://invent.kde.org/davidedmundson/qtwayland/-/tree/reconnect_main Qt's usage is slightly more complicated than SDL, but still the changes are still relatively small and managable. I have been running this for the best part of 6 months, and everything "just works". I've thrown games, full IDE's (kdevelop) and image edtiors at this and everything works flawlessly without client changes. This is slightly held back by us having to be API and ABI compatible with the frozen Qt5 base, a change landing in Qt6 could potentially address this cleaner, especially the part about refreshing the QBackingStore. Note that if running Qt on Plasma we have a "plasma-integration" plugin that also makes some wayland calls that has also needed adjusting. The wiki (https://invent.kde.org/plasma/kwin/-/wikis/Restarting) lists all repositories and pending changes. ## XWayland (somewhat WIP): https://gitlab.freedesktop.org/davidedmundson/xserver/-/tree/reconnections Xwayland was a whole new adventure, but the code for resending windows was very simple even tackling details like pointer constraints. Being xwayland it even retains positional information as the X client itself remains intact. The biggest challenge here is that the compositor typically starts Xwayland and does so with custom file descriptors for direct connections. That obviously doesn't work for handling the compositor changing. This required quite a lot of reshuffling about--moving XWwayland spawning to the wrapping helper, as well as adding new mutexes to handle startup being announced. Ultimately everything was do-able. Messy branches for that are available on request. ## Other toolkits. One nice thing is that it's completely opt-in on the client. For some system services (i.e plasmashell ) just restarting is a perfectly acceptable approach. For wl-paste, it may as well just exit. Firefox h
Re: Compositor handoffs: Switching clients between compositors
> FYI we did this a few years back for efl and enlightenment... on a loss of the Yeah, it's good stuff. I'm forced to go a bit lower as I'm trying to retroactively support applications that have some pre-existing assumptions, but overall the idea is the same. > we added an extended protocol for the compositor to send a UUID to the client > per surface and clients on reconnect provide that UUID to the compositor - > this > allows the compositor to fix all the stacking and other state when the > surfaces > come back. :) > > https://git.enlightenment.org/core/enlightenment.git/tree/src/protocol/session-recovery.xml > Thanks. We had taken a look at that. The Xdg session protocol that I mention we hope to expand on is built on top of this with the same base principle. We haven't yet tried really making use of it. > i think in theory efl apps should then work with your hand-off (for us its > session recovery but that is your intent too - handling compositor crashes >i think in theory efl apps should then work with your hand-off I gave it a go with efl git and the enlightenment terminal. It unfortunately crashes, but I didn't look into the cause. Based on the trace, it did look like it was trying to reconnect. David
RE: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable
I have some comments/questions on the current v6 interface which I'd like clarifying before we make it stable. The Positioner anchor and gravity both takes the edge as a bitfield of flags. It's then part of the protocol to say "If two parallel anchor edges are specified (e.g. 'left' and 'right'), the invalid_input error is raised." I don't understand why we don't use 9 enum values; none, topleft, top, topright etc. as it forbids even the possibility of an invalid input. It's what we do in the top level resize edge. It seems cleaner and safer wtih no drawbacks Also on the positioner, when I have an offset from an anchor what is the intended behaviour in the compositor for applying this if I end up flipping or sliding due to constraints? Any user interface element isn't going to line up after it's constrained in the same axis as the offset...unless we allow clients to specify an offset for every possible constraint. Regards David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable
You missed a line in "xdg-shell/positioner: Allow empty anchor_rect" You might want to squash this with that. From 0a21378302d63a83a10723b41adf35e605fb35f5 Mon Sep 17 00:00:00 2001 From: David Edmundson Date: Tue, 20 Jun 2017 18:29:59 +0100 Subject: [PATCH 1/2] Fix xdg-shell/positioner: Allow empty anchor_rect --- stable/xdg-shell/xdg-shell.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml index 2e845fa..ffba86d 100644 --- a/stable/xdg-shell/xdg-shell.xml +++ b/stable/xdg-shell/xdg-shell.xml @@ -165,7 +165,7 @@ Specify the anchor rectangle within the parent surface that the child surface will be placed relative to. The rectangle is relative to the window geometry as defined by xdg_surface.set_window_geometry of the - parent surface. The rectangle must be at least 1x1 large. + parent surface. When the xdg_positioner object is used to position a child surface, the anchor rectangle may not extend outside the window geometry of the -- 2.12.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable
From 093ed1a17a483792e316f932e15a566ab2653838 Mon Sep 17 00:00:00 2001 From: David Edmundson Date: Tue, 20 Jun 2017 18:51:45 +0100 Subject: [PATCH 2/2] xdg-shell/positioner: Replace edge bitfield with extended enum Bitfields allowed for impossible combinations of anchor edges, such as being on the left and right edge. Use of explicit enumerations means we don't need to handle that case. --- stable/xdg-shell/xdg-shell.xml | 71 ++ 1 file changed, 30 insertions(+), 41 deletions(-) diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml index ffba86d..020af9e 100644 --- a/stable/xdg-shell/xdg-shell.xml +++ b/stable/xdg-shell/xdg-shell.xml @@ -179,63 +179,52 @@ - - - - - - + + + + + + + + + + + Defines a set of edges for the anchor rectangle. These are used to derive an anchor point that the child surface will be positioned - relative to. 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 position of the rectangle); otherwise, the derived - anchor point will be centered on the specified edge, or in the center of - the anchor rectangle if no edge is specified. - - If two parallel anchor edges are specified (e.g. 'left' and 'right'), - the invalid_input error is raised. + relative to. The anchor point will be in the specified corner, in the center +of a specified edge, or in the center of the anchor rectangle if no edge +is specified. + summary="anchor edge"/> - - - - - - + + + + + + + + + + - Defines in what direction a surface should be positioned, relative to - the anchor point of the parent surface. If two orthogonal gravities are - specified (e.g. 'bottom' and 'right'), then the child surface will be - placed in the specified direction; otherwise, the child surface will be - centered over the anchor point on any axis that had no gravity - specified. - - If two parallel gravities are specified (e.g. 'left' and 'right'), the - invalid_input error is raised. + Defines which edge of the surface should be positioned relative to + the anchor of the parent surface. The anchor point will be in the specified corner, +in the center of a specified edge, or in the center of the anchor rectangle if no edge +is specified. + summary="gravity direction"/> -- 2.12.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable
> > > > > > I suggest continuing talking about "direction" here. An alternative to > the above could be, changing the original text just a bit: > The thing I struggled with when trying to first understand v6 is that "bottom" isn't a direction, it's a position. I've changed it in a way that still keeps the concept of direction, but with a slightly different wording. From 4e5fa5bf4bebe3c06d7172e2dcf13194278deb0c Mon Sep 17 00:00:00 2001 From: David Edmundson Date: Tue, 20 Jun 2017 18:51:45 +0100 Subject: [PATCH] xdg-shell/positioner: Replace edge bitfield with extended enum Bitfields allowed for impossible combinations of anchor edges, such as being on the left and right edge. Use of explicit enumerations means we don't need to handle that case. Signed-off-by: David Edmundson --- stable/xdg-shell/xdg-shell.xml | 80 +++--- 1 file changed, 36 insertions(+), 44 deletions(-) diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml index ffba86d..fc50ae6 100644 --- a/stable/xdg-shell/xdg-shell.xml +++ b/stable/xdg-shell/xdg-shell.xml @@ -179,63 +179,55 @@ - - - - - - + + + + + + + + + + - - Defines a set of edges for the anchor rectangle. These are used to - derive an anchor point that the child surface will be positioned - relative to. 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 position of the rectangle); otherwise, the derived - anchor point will be centered on the specified edge, or in the center of - the anchor rectangle if no edge is specified. - - If two parallel anchor edges are specified (e.g. 'left' and 'right'), - the invalid_input error is raised. + +Defines the anchor point for the anchor rectangle. The are used +to derive an anchor point that the child surface will be +positioned relative to. If a corner anchor is set (e.g. +'top_left' or 'bottom_right'), the anchor point will be at the +specified corner; otherwise, the derived anchor point will be +centered on the specified edge, or in the center of the anchor +rectangle if no edge is specified. + summary="anchor"/> - - - - - - + + + + + + + + + + - Defines in what direction a surface should be positioned, relative to - the anchor point of the parent surface. If two orthogonal gravities are - specified (e.g. 'bottom' and 'right'), then the child surface will be - placed in the specified direction; otherwise, the child surface will be - centered over the anchor point on any axis that had no gravity - specified. - - If two parallel gravities are specified (e.g. 'left' and 'right'), the - invalid_input error is raised. +Defines in what direction a surface should be positioned, +relative to the anchor point of the parent surface. If a corner +gravity is specified (e.g. 'bottom_right' or 'top_left'), then +the child surface will be placed towards the specified gravity; +otherwise, the child surface will be centered over the anchor +point on any axis that had no gravity specified. + summary="gravity direction"/> -- 2.12.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable
> > For flipping, it's a bit more non straight forward, as > flipping and the offset are not very useful in combination, > Yes, I think it's only when flipped where we need some additional clarification. > How about we add the following paragraph to the flip_x/y descriptions: > > The adjusted position is calculated given the original anchor > rectangle and offset, but with the new flipped anchor and gravity > values. > I'm not sure that's what we want. In the case of a combobox where we want the dropdown to appear beneath the main UI controls with a gap, if we don't flip the offset we'll end up now overlapping the controls. To hopefully explain what I mean: http://static.davidedmundson.co.uk/not_flipped.png - some popup anchored to the text box (anchor bottom, gravity bottom) some +y offset. Now for some reason that's constrained and it has flipY. http://static.davidedmundson.co.uk/flipped.png - now flipped (anchor top, gravity top) but because we have a positive offset, we end up overlapping the control we're anchored round. I don't fully grasp what the anchor offset is for. A toolkit can acheive the same functionality by simply making the anchor rect bigger and that implicitly also gives the client the flexibility on how an offset when flipped should be handled. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH] Add xdg-output protocol
I don't understand what we gain by sending the position again in global compositor space, it will always match the position of the wl_output. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording
Can you clarify something here. >A newly-unmapped surface is considered to have met condition (1) out + of the 3 required conditions for mapping a surface if its role surface + has not been destroyed. Attaching a null buffer unmaps the surface Unmapping the surface resets the state The above implies if we haven't deleted the xdg_toplevel we don't need to call get_toplevel again. When the client wants to remap, what prompts the server to send a new configure event? If it doesn't, how does the client know what the state is before it reattaches a buffer. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording
> > The idea is that having unmapped by null-attach means the > xdg_surface/xdg_toplevel etc is reset to the exact same state that it > had when first created, thus to map again, one would do what one would > do the same as when mapping it for the first time: set up the state > (set_title, (set_maximized?), set_app_id), commit, wait for configure, > then attach a new buffer given the configure event data. > > > Thanks, I'd totally forgotten the commit as I was only looking in this interface. It's clear now. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces
> I was thinking more of e.g. Qt (or any other toolkit) that supports > wl_shell, xdg_shell unstable v5 and v6 (albeit to a wildly differing > extent sadly) and would now have to drop unstable v5 in order to > support xdg_wm_base. Also, I think both KWin and Qt did only support > unstable v5 until very recently. wl_shell is always available as > fallback though. > To expand on the current state of Qt and Kwin. Qt clients supports wl_shell, xdgv5 and xdgv6. If the server anounces xdgv6, it uses that, however even if the server anounces xdgv5 it will still ignore it and use wl_shell instead unless explicitly forced by environment variables. KDE Plasma does not set those variables. Kwin supports wl_shell, xdgv5 (though because of the above literally no-one uses it except for some unit tests) xdgv6 is all done and waiting merge. Theoretically we could support v5, v6 and v4732 all at once due to the layers of abstraction that both Kwin and Qt do, and we would use the wayland scanner flag to make that happen if it existed, but practically speaking if we dropped v5 support when we added "v7" it wouldn't impact anyone. David ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Add the KDE server decoration protocol
The server decoration protocol negotiates between the client and server whether the client should default to drawing window decorations, and informs the compositor what the client is doing. This is useful not just for a compostior that is doing decorations itself, but much more importantly for a toolkit, such as Qt which primarily targets embedded and IVI applications, not to have to modify clients to add a header bar which makes them usable on a desktop compositor. This file is currently copied in multiple places across GTK, Sway as well as being needed in both Qt and KDE. We should have this in a shared place. --- unstable/server-decoration/server-decoration.xml | 94 1 file changed, 94 insertions(+) create mode 100644 unstable/server-decoration/server-decoration.xml diff --git a/unstable/server-decoration/server-decoration.xml b/unstable/server-decoration/server-decoration.xml new file mode 100644 index 000..8bc106c --- /dev/null +++ b/unstable/server-decoration/server-decoration.xml @@ -0,0 +1,94 @@ + + + + + +This interface allows to coordinate whether the server should create +a server-side window decoration around a wl_surface representing a +shell surface (wl_shell_surface or similar). By announcing support +for this interface the server indicates that it supports server +side decorations. + + + +When a client creates a server-side decoration object it indicates +that it supports the protocol. The client is supposed to tell the +server whether it wants server-side decorations or will provide +client-side decorations. + +If the client does not create a server-side decoration object for +a surface the server interprets this as lack of support for this +protocol and considers it as client-side decorated. Nevertheless a +client-side decorated surface should use this protocol to indicate +to the server that it does not want a server-side deco. + + + + + + + + + + + + + This event is emitted directly after binding the interface. It contains + the default mode for the decoration. When a new server decoration object + is created this new object will be in the default mode until the first + request_mode is requested. + + The server may change the default mode at any time. + + + + + + + + + + + + + + + + + + + + + This event is emitted directly after the decoration is created and + represents the base decoration policy by the server. E.g. a server + which wants all surfaces to be client-side decorated will send Client, + a server which wants server-side decoration will send Server. + + The client can request a different mode through the decoration request. + The server will acknowledge this by another event with the same mode. So + even if a server prefers server-side decoration it's possible to force a + client-side decoration. + + The server may emit this event at any time. In this case the client can + again request a different mode. It's the responsibility of the server to + prevent a feedback loop. + + + + + -- 2.14.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Use-case when positioning a window is necessary
>And that is where positioning is necessary: to not occlude the line of text where the cursor is, and to show the documentation at a sensible place (near the cursor position). xdg-foreign will just get that window on top. You don't have any control of where on top it is, merely a child-parent relationship It will occlude or be nowhere near the cursor. xdg-foreign alone won't be a complete solution. David
Re: what are the protocol rules about uniqueness of event and request names?
The generated C code be full of conflicts. The MY_PROTOCOL_REQUESTEVENT_SINCE_VERSION define for a start. I think it might compile in C, but other generators exist that might not and it's making life much more confusing than it needs to be. I would strongly avoid it. David
Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston
On Fri, Feb 23, 2024 at 6:15 AM Terry Barnaby wrote: >I don't know how to determine the Wayland surface ID from a > wl_surface pointer unfortunately to really check this. wl_proxy_get_id(static_cast(myWlSurface)); > >> Possibly when QWidget is below in hierarcy to be a child of of a parent, > >> as described in That's fine. A QWidget with WA_NativeWindow will create a QWindow with a parent. A QWindow with a parent will create a subsurface in wayland terms. But it is a subsurface where Qt is managing it and you're also committing on it, which can be a bit confusing and going through widgets to create a subsurface isn't really needed. There's a bunch of other options there. --- Can you link your test app. You can send me a private email and I'll take a look. It doesn't seem like a core wayland problem more a Qt/application setup issue so far. Then we can follow it up on Qt's Jira if there is a Qt issue. David Edmundson - QtWayland Maintainer
