dnkl
/
fuzzel
5
49
Fork 16
Code Issues 20 Pull Requests 2 Releases 18 Activity
Labels Milestones
New Issue

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

Open
opened 5 months ago by VannTen · 5 comments
VannTen commented 5 months ago

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.
dnkl commented 5 months ago
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?
VannTen commented 5 months ago
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.
dnkl commented 5 months ago
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.
VannTen commented 5 months ago
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 ?
dnkl commented 5 months ago
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 Branch/Tag Specified
Branches Tags
key-bindings
master
releases/1.0
releases/1.1
releases/1.2
releases/1.3
releases/1.4
releases/1.5
releases/1.6
releases/1.7
Labels
Apply labels
Clear labels
bug
Something is not working duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong performance question
More information is needed wontfix
This won't be fixed
No Label bug duplicate enhancement help wanted invalid performance question wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/fuzzel#110
Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch '%!s(<nil>)'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes