Closed izmyname closed 2 weeks ago
Also, @Vladimir-csp tagging you to review in case I forgot to mention something.
I think this section needs to be integrated in some shape or form. The "full experience" is to place compositor unit in session.slice
and run apps as units via uwsm app
or analogs, this way uuctl
and fumon
tools also become more useful.
I don't even know why these two are here. They're automatically set by Hyprland.
IIRC Hyprland passes them through if not mentioned in config, but already present in the environment (typical for DM/SM setup). ...yep
As for
XDG_SESSION_DESKTOP
, what uses it?
Systemd uses it, described in man pam_systemd
.
I think this section needs to be integrated in some shape or form. The "full experience" is to place compositor unit in
session.slice
and run apps as units viauwsm app
or analogs, this wayuuctl
andfumon
tools also become more useful.
Makes sense to put it on a specific page I mentioned in the initial comment. Although, honestly, I didn't try uwsm app and not 100% sure how it works.
Oops, I messed up this one.
Systemd-managed session implies running apps in units. If something is spawned directly by Hyprland, it will be a part of compositor's unit which is not ideal (to say the least). Also it is recommended to put compositor into session.slice
(for its resources and priorities), which most apps should not be in. See man systemd.special
.
Compositor can be placed into session.slice
by adding -S
to uwsm start
or having UWSM_USE_SESSION_SLICE=true
in user's environment (profile or environment.d).
Apps (also things that do not have a systemd unit, run continuously, and are not related to the compositor) need to be wrapped in units by executing them via uwsm app
or uwsm-app
or app2unit, or directly via systemd-run --user ...
. Examples:
# run some continuous session-related script
exec-once = exec uwsm app -a some-ipc-script ~/bin/my-ipc-script.sh
# fuzzel launcher
bind = SUPER, R, exec, exec fuzzel --launch-prefix='uwsm app --`
# run qterminal
bind = SUPER, T, exec, exec uwsm app qterminal.desktop
# run pcmanfm
bind = SUPER, E, exec, exec uwsm app pcmanfm-qt.desktop
Unit type is scope by default, because it behaves like simple commands. But it can be switched to service to gain more flexibility and journald logging. -t service
argument for uwsm app
or UWSM_APP_UNIT_TYPE=service
in environment to set default.
uwsm app
also puts units into custom *-graphical.slice
s that receive deactivation action during shutdown.
IMHO, needs to be shortened and simplified, so we could add a quick instruction ( see https://wiki.hyprland.org/Useful-Utilities/). Long version is better to be put somewhere in readme on uwsm side, so we could provide a link to it.
Speaking of adding another page for uwsm @fufexan should it be done by me, in this pr, or somehow else? Alternately, though, we could put uwsm in "Other" or "Must have" section
You can create a new page under Useful Utilities in this PR.
Oh wait, I just noticed Hyprland wiki already mentions uwsm. https://wiki.hyprland.org/Useful-Utilities/Other/
Should I keep the new page or leave just that mention?
Keep the new page, and remove the mention from Other.
Okay, done. I'll revisit the page later to add installation instructions and links to other wiki pages, if needed.
@fufexan need (probably) better installation instruction for Nix/NixOs
Also, links to other wiki pages need to be rechecked
I'm not sure whether my comments were seen, as they were in pending state and I'm not that familiar with github.
@Vladimir-csp I tried to launch uwsm app wl-paste --watch cliphist store
, but it resulted in error as uwsm coudn't handle --watch cliphist store
. Am I missing something? Also, should we use uwsm app
with flatpak apps, taking into account xdph doesn't implement org.freedesktop.Background
? And can we use one exec-once entry to launch several programs with uwsm app
, like exec-once = uwsm app foo & uwsm app bar&
?
@izmyname use uwsm app -- wl-paste --watch cliphist store
, as mentioned in the man page:
Always use "--" to disambiguate dashed arguments intended for application itself.
And can we use one exec-once entry to launch several programs with
uwsm app
, likeexec-once = uwsm app foo & uwsm app bar&
?
Why not have them on separate lines?
use
uwsm app -- wl-paste --watch cliphist store
Uh, I'm an idiot. My bad.
Why not have them on separate lines?
Force of habit
UPD: chaining multiple commands within one exec-once works, btw
Also, should we use uwsm app with flatpak apps, taking into account xdph doesn't implement org.freedesktop.Background?
No ATM, since flatpak handles units its own way.
And can we use one exec-once entry to launch several programs with uwsm app, like exec-once = uwsm app foo & uwsm app bar&?
It's shell, so why not.
No ATM, since flatpak handles units its own way.
Plus, things like telegram and easy effects are meant to be autostarted with xdg-autostart, using desktop entries, but xdph doesn't allow that, for now.
Also, another problem I should probably report to uwsm github (will do it tomorrow) - Hyprland no longer exits via loginctl command, immediately. All systemd services are stopped, but Hyprland, itself (and flatpak apps) stays active with its default wallpaper placeholder, for like a minute or two, before logging me out. I'll try to reproduce it tomorrow, though.
As for the PR, itself - I'll add an example exec-once
command in the wiki and, if everything else is ok, it's ready for merging.
Plus, things like telegram and easy effects are meant to be autostarted with xdg-autostart, using desktop entries, but xdph doesn't allow that, for now.
Why?
Plus, things like telegram and easy effects are meant to be autostarted with xdg-autostart, using desktop entries, but xdph doesn't allow that, for now.
Why?
Because of lacking org.freedesktop.Background
implemetation. The settings within flatpaks simply won't allow creating a desktop entry.
Ah, you mean flatpak itself can not put entries into ~/.config/autostart due to portal issues?
Exactly. Additionally, in case of Easy Effects - if I try to access its settings and get a warning about lacking access to Background implementation - it won't stay as a background process, after I open it, then close, so I have to reset its settings in order to be able both daemonize and access it.
@fufexan tagging for the final (probably) review
I removed gdb
make dependency for Arch from installation page. Hyprland builds just fine without it, and Arch dropped it for their PKGBUILD in extra repo.
Exactly. Additionally, in case of Easy Effects - if I try to access its settings and get a warning about lacking access to Background implementation - it won't stay as a background process, after I open it, then close, so I have to reset its settings in order to be able both daemonize and access it.
Hm. I've just realized I'm exploiting a vulnerability to bypass portal background permission and daemonize Easy Effects. Curious.
https://github.com/hyprwm/Hyprland/pull/8376 and https://github.com/hyprwm/Hyprland/pull/8339 discussion
Probably, need to add another page to mention uwsm with short instructions. Startup or something
Corrections, reviews and suggestions are welcome.