Feature Request: option to suffix `--launch-prefix` command with .desktop file name #110

Open
opened 5 months ago by VannTen · 5 comments

This probably only make sense in conjunction with --launch-prefix,

The usecase I'm thinking of is to launch applications in systemd scopes/services whose names is derived from the desktop file (see https://systemd.io/DESKTOP_ENVIRONMENTS/ for the motivation).

My idea is to use a systemd-run wrapper for that, which would be invoked this way :
wrapper <desktop-file-name> <executable + arguments>.

(There might me be other use case, there is nothing related to systemd in the concept itself).

Would you be open to such a feature ? I can probably make a PR, since I suppose fuzzel already has that information.

This probably only make sense in conjunction with `--launch-prefix`, The usecase I'm thinking of is to launch applications in systemd scopes/services whose names is derived from the desktop file (see https://systemd.io/DESKTOP_ENVIRONMENTS/ for the motivation). My idea is to use a systemd-run wrapper for that, which would be invoked this way : `wrapper <desktop-file-name> <executable + arguments>`. (There might me be other use case, there is nothing related to systemd in the concept itself). Would you be open to such a feature ? I can probably make a PR, since I suppose fuzzel already has that information.
Owner

I'm not sure I understand your use case... can you give a couple of concrete examples?

I'm not sure I understand your use case... can you give a couple of concrete examples?
Poster

Sure.

Currently, I use fuzzel with --launch-prefix=wrapper.sh.
wrapper.sh is something like that:

#!/bin/bash
app=$1
shift
systemd-run --unit=${app}@${RANDOM} -- ${app} $@

(the point of using systemd-run is mostly to place applications in their own cgroup, which allows stuff like early oomd killer to selectively kill applications instead of taking down the whole sessions)

Using a know unit name allows to override default, adjust resources limiting, stuff like that.

However using the executable as the "application id" is not ideal: it can change between distribution (in case of name conflicts) and it does not always map to the application name (as presented in fuzzel).

So I'm trying to use the desktop file name instead, which is supposed to be a bit more standardized and unique.

Currently, taking Lutris as an example, the launcher is invoked like this :
wrapper.sh lutris

The idea would to instead invoke it like this (when using the option) :
wrapper.sh net.lutris.Lutris.desktop lutris

with a launcher a bit different :

#!/bin/bash
appID=$1
shift
systemd-run --unit=${appID}@${RANDOM} -- $@

Does that make sense ?

To sum it up, the idea would be to pass along the desktop file name.

Sure. Currently, I use fuzzel with `--launch-prefix=wrapper.sh`. `wrapper.sh` is something like that: ``` #!/bin/bash app=$1 shift systemd-run --unit=${app}@${RANDOM} -- ${app} $@ ``` (the point of using systemd-run is mostly to place applications in their own cgroup, which allows stuff like early oomd killer to selectively kill applications instead of taking down the whole sessions) Using a know unit name allows to override default, adjust resources limiting, stuff like that. However using the executable as the "application id" is not ideal: it can change between distribution (in case of name conflicts) and it does not always map to the application name (as presented in fuzzel). So I'm trying to use the desktop file name instead, which is supposed to be a bit more standardized and unique. Currently, taking Lutris as an example, the launcher is invoked like this : `wrapper.sh lutris` The idea would to instead invoke it like this (when using the option) : `wrapper.sh net.lutris.Lutris.desktop lutris` with a launcher a bit different : ``` #!/bin/bash appID=$1 shift systemd-run --unit=${appID}@${RANDOM} -- $@ ``` Does that make sense ? To sum it up, the idea would be to pass along the desktop file name.
Owner

It's a very special use case... might be better to simply define a set of environment variables fuzzel sets before exec:ing launch-prefix, and leave the details to the wrapper script.

It's a very special use case... might be better to simply define a set of environment variables fuzzel sets before exec:ing `launch-prefix`, and leave the details to the wrapper script.
Poster

I did not think about that, but I agree, that would probably be a better fit.
Something like DESKTOP_FILE_NAME for example ?

I did not think about that, but I agree, that would probably be a better fit. Something like DESKTOP_FILE_NAME for example ?
Owner

Yeah, though I'd prefix all exported environment variables with FUZZEL_. There are probably a couple of more things we can export that would be useful, but let's start with FUZZEL_DESKTOP_FILENAME.

Yeah, though I'd prefix all exported environment variables with `FUZZEL_`. There are probably a couple of more things we can export that would be useful, but let's start with `FUZZEL_DESKTOP_FILENAME`.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/fuzzel#110
Loading…
There is no content yet.