search

swaywm / wlr-protocols

Wayland protocols designed for use in wlroots (and other compositors)
122 stars 29 forks source link

wlr-foreign-toplevels pid #77

Closed damianatorrpm closed 4 years ago

damianatorrpm commented 4 years ago

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!

A solution is to provide the PID and than being able to find the binary. Consider adding the PID to wlr-foreign-toplevels

emersion commented 4 years ago

This is completely broken by design, especially in the times of flatpak and snap.

The PID isn't a good solution because:

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!

What you describe sounds like a more general problem. I think you should open an issue in wayland-protocols to talk about this.

damianatorrpm commented 4 years ago

What you describe sounds like a more general problem. I think you should open an issue in wayland-protocols to talk about this.

I tried if you mean https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues but I do not see the the new issuse/create issue button.

EDIT: found it Additionally I have send this to wayland-devel under thread name

appId title / Iconic dock launchers

The suggestion was to use PID.

David Edmundson david@davidedmundson.co.uk | David Edmundson david@davidedmundson.co.uk | Sun, Apr 12, 3:13 PM (2 days ago) | David Edmundson david@davidedmundson.co.uk to me, wayland-devel | to me, wayland-devel to me, wayland-devel

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.

emersion commented 4 years ago

Duplicate of https://github.com/swaywm/wlr-protocols/issues/57