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 <da...@davidedmundson.co.uk> 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
