appId title / Iconic dock launchers

Damian Ivanov damianatorrpm at gmail.com
Sun Apr 12 19:31:54 UTC 2020


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
<david at 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


More information about the wayland-devel mailing list