feat: exec, based on the branch from oknozor

[wiiznokes]

No description provided.

[Drakulix]

Honestly I don't think moving the exec code into fde is such a great idea, because how we launch applications is a bit special especially regarding gpu code.

If we still want to consider this crate to be somewhat generic, I think this should live in a separate library or possibly libcosmic. (The de-duplication of code is still very welcome).

Additionally breaking the XDG_ACTIVATION_TOKEN and DESKTOP_STARTUP_ID logic is a no-go and needs cooperation from the application, as that is the only way to obtain such a token. (But I guess this missing is part of why this is a Draft.)

Also I don't believe the graphics code matches what we currently have in cosmic-launcher/app-library/app-list and that is a problem. This looks like a re-implementation of switcheroo, which gets a bunch of things wrong imo (e.g. hiding other gpus from applications instead of only setting the preferred one and messing with the ICDs).

Plus we have plans to extend this logic in the future to make use of some cosmic-exclusive tricks. So I would really appreciate if we wouldn't modify the logic in the meantime and just use switcheroo like the current implementation does.

[Drakulix]

Also, another constraint: the gnome-cosmic session still needs to be able to exec the desktop file itself.

[wiiznokes]

@Drakulix Hi, tbh, i didn't looked much in the GPU code of this PR yet, but from what i saw of in the launcher, most of it will have to get replaced.

The launcher use switcheroo_control to gets all the gpu info. I guess we could add a parameter on the launch functions that take a set of env variables, to let cosmic-component managing this. And feature flag the logic behind prefers_non_default_gpu.

Additionally breaking the XDG_ACTIVATION_TOKEN and DESKTOP_STARTUP_ID logic is a no-go and needs cooperation from the application, as that is the only way to obtain such a token. (But I guess this missing is part of why this is a Draft.)

Indeed, this is still todo, but from what i understand, this use dbus to request some ids, and also set some env variables when launching the new process. I think it will fit well in this crate.

Let me know if you think this will works. The problem of using libcosmic for this is that the service launcher doesn't depend on it.

[wiiznokes]

If anyone wondering, i don't think this will be suitable for cosmic because of this:

https://github.com/Smithay/client-toolkit/blob/c583de8dd5651f8168c6513cd282137c42aae049/src/activation.rs#L99 and https://github.com/Smithay/client-toolkit/blob/c583de8dd5651f8168c6513cd282137c42aae049/src/activation.rs#L46

/// Warning: Many compositors will issue invalid tokens for requests from
/// unfocused surfaces. There is no way to detect this from the client-side.

So since the service have no active surface, it must be cosmic-launcher that request the token.

Except this, there is some useful code in this pr to parse the exec field