Protocol backwards compatibility requirements?
Hi all, This is request for comments on the exact requirements for protocol backwards compatibility for clients binding to new versions of an interface. Reason for this are the high-resolution wheel scrolling patches: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72 Specifically, the question is: do we **change** protocol elements or behaviour as the interface versions increase? A few random examples: - event wl_foo.bar introduced in version N sends a wl_fixed in surface coordinates. version N+1 changes this to a normalized [-1, +1] range. - request wl_foo.bar introduced in version N takes an int. version N+1 changes wl_foo.bar to take a wl_fixed and an enum. - request wl_foo.bar introduced in version N guaranteed to generate a single event wl_foo.baz. if the client binds to version N+1 that event may be sent zero, one or multiple times. I think these examples cover a wide-enough range of the possible changes. My assumption was that we only ever add new requests/events but never change existing behaviour. So wl_foo.bar introduced in version N will always have the same behaviour for any interface N+m. I've seen some pushback for above linked patchset because it gets complicated and suggestions to just change the current interface. The obvious advantage is being able to clean up any mess in the protocol. The disadvantages are the breakage of backwards compatibility with older versions. You're effectively forcing every compositor/client to change the code based on the version number, even where it's not actually needed. Or, IOW, a client may want a new feature in N+2 but now needs to implement all changes from N+1 since they may change the behaviour significantly. So... what's our official stance on protocol backwards compatibility requirements for clients binding to new versions? The last bit is important, this is not a discussion about an changing existing version, merely about future ones and binding to newer versions is opt-in for both compositor and client. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: appId title / Iconic dock launchers
Hello David, Thanks for the response. >You do have the pid from the client. From that you have the path to >the "actual binary" already. Ah yes, this would probably solve that. >X11 startup notifications. I am not really that familiar with those and they do not seem to be available on wayland. To me even uncommon cases like launching the exec line of a desktop file without the shell after being confused about it are important. Anyways finding the actual binary via pid seems good, appreciated! Br, Damian On Sun, Apr 12, 2020 at 3:13 PM David Edmundson wrote: > > 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: 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
appId title / Iconic dock launchers
Hello, Below appears to affect all wayland compositors / environments (and X), respectively any panel / dock that has the ability to pin an application for quick launching when all it's surfaces are closed. wayland api provides the appId / title (IIRC this is the xdg-shell protocol) X api provides the appId / title / icon custom wayland wlroots protocol wlr-foreign-toplevel-management provides the same The implementation of all desktops environments face the following problem, they need to match the appId to a desktop file to create a launcher, which is done by looking up in all the directories $XDG_DATA_DIRS until a desktop file matching the appId is found. This is completely broken by design, especially in the times of flatpak and snap. As an example take $application, it can be installed 1) from system package - desktop file goes into /usr/share/applications/ 2) from local build - desktop file goes into /usr/local/share/applications/ 3) from flatpak(system wide) - desktop file goes into /var/lib/flatpak/share/applications/ 4) from flatpak(user wide) - desktop file goes into $HOME/.local/share/applications/ 5) from flatpak(custom loc) - desktop file goes into $custom 6) from snap - desktop file goes into snap directory 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! How can wayland help solve this problem? I imagine it could be possible additionally to appId and title to expose maybe the path to the actual binary? I'd be happy to hear some ideas to resolve this for all Linux desktop environments. Br, Damian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: can subsurface and shell surface be used together to manage surfaces
Hi Matt yes, I want to bind a wl_surface to a subsurface first, then create a shell surface for it. I want to do that is because if the wl surface is created by another compositor, it had been declared as a subsurface to map its position of original compositor. Then weston shell can't manage the surface as a window directly, I was just wondering how can make weston shell could manage these kind of surfaces as separate windows too. It seems create shell surface for each wl surface is not a good idea in this case. Thank you for confirmation! Best Regards Nancy Matt Hoosier 于2020年4月11日周六 下午9:38写道： > If you’re asking whether it’s possible to migrate a given wl_surface from > being a subsurface (initially) to later being a shell surface, this isn’t > allowed. This has to do with the immutability of a surface’s so-called > “role.” (Surfaces are only ever allowed to be registered with one given > role. ) > > -Matt > > On Fri, Apr 10, 2020 at 5:43 AM zou lan wrote: > >> Hi pekka & all >> >> I want to use subsurface to manage the initial position of each surface >> on screen, then I want to create shell surface for each wl surface to >> manage them seperately, such as response touch event, ivi-shell can modify >> the z-order of each surface and move each ivi surface to different displays. >> >> Is it ok to use subsurface like this? If the shell surfaces' z-order have >> been modified by desktop shell or ivi-shell, will the z-order of >> subsurfaces be modified too? >> >> thank you! >> >> Best Regards >> Nancy >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
