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
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.
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
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
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
