sway-systemd icon indicating copy to clipboard operation
sway-systemd copied to clipboard

Improve detection of launched applications

Open alebastr opened this issue 4 years ago • 5 comments

Detection of apps for assign-cgroups script is currently completely reliant on an i3 IPC interface provided by the compositor/window manager. That is fine and it should cover most of resource intensive applications.

Assuming that the autostart is already handled by systemd-xdg-autostart-generator, there are still a few things I'd like to put into cgroups:

  • special applications (layer-shell)
  • apps that are started minimized to tray (i.e. some heavy background process with a tray icon to control).
  • ...?

alebastr avatar Feb 20 '21 22:02 alebastr

What are you thoughts on using systemd-run for launching applications and ensuring they end up in the correct cgroups ? Ie implement the "XDG standardization for applications" in https://systemd.io/DESKTOP_ENVIRONMENTS/ by using a wrapper around systemd-run --unit=${app_id}@${RANDOM} -- ${cmd} ?

Downside is that this requires the launcher / context be aware of that app_id.

(AFAICT the "ApplicationID" should roughly map to the desktop file name).

VannTen avatar Jul 07 '22 07:07 VannTen

I stopped looking into that direction when I found that none of the launchers I'm aware of can provide app_id. I.e. if you take rofi -show drun, wofi, fuzzel, nwg-anything, etc, you won't be able to pass the selected .desktop file name to an arbitrary wrapper command.

It is possible to take a command name instead of app_id, and here's a script that I use to start CLI apps this way. I just don't want to resort to that for GUI apps.

BTW, if you have a .desktop file name and your glib2 package is built with https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1596 (I know that at least Fedora applies that patch), gtk-launch will spawn the process in the correct scope.

alebastr avatar Jul 07 '22 18:07 alebastr

I stopped looking into that direction when I found that none of the launchers I'm aware of can provide app_id. I.e. if you take rofi -show drun, wofi, fuzzel, nwg-anything, etc, you won't be able to pass the selected .desktop file name to an arbitrary wrapper command.

Yeah, I know. I've opened an issue for fuzzel and the maintainer is not opposed to it (in the form of an environment variable), I just need to write the patch. (I'll do. Eventually)

It's not exactly a standard yet, so maintainers are not necessarily going to be okay with that.

It is possible to take a command name instead of app_id, and here's a script that I use to start CLI apps this way. I just don't want to resort to that for GUI apps.

Why do you treat those differently if I may ask ?

-- Max Gautier

VannTen avatar Oct 11 '22 08:10 VannTen

So I implemented this in fuzzel : https://codeberg.org/dnkl/fuzzel/pulls/145 I now use this script as the launch-prefix for fuzzel :

systemd-run-desktop-id

#!/bin/bash
systemd-run --user \
    --unit=app-fuzzel-${FUZZEL_DESKTOP_FILE_ID%.desktop}@${RANDOM} \
    --slice=app-${FUZZEL_DESKTOP_FILE_ID%.desktop}-${RANDOM} \
    -- $@

I'm not really sure what should be in (as proposed in https://systemd.io/DESKTOP_ENVIRONMENTS/ ) though. Maybe rather $XDG_CURRENT_DESKTOP than "fuzzel" ? Any thoughts ?

VannTen avatar Jul 12 '23 09:07 VannTen

I'm also wondering if this could help with #6 , by using the launcher to set environment variable :thinking: ... It will still only works in fuzzel (yet) ofc...

VannTen avatar Jul 12 '23 11:07 VannTen