Talk:Hyprland

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 12:10, 5 November 2024 (UTC)
:: Your reply ~~~~

Executing Hyprland

Talk status

This discussion is done.

Why not add Hyprland to "~/.bash_profile":

FILE ~/.bash_profileLaunch Hyprland after logging into the first TTY

if [ -z "${WAYLAND_DISPLAY}" ] && [ "${XDG_VTNR}" -eq 1 ]; then
    dbus-run-session Hyprland
fi

Which might also make the if clause obsolete, as it is only started on a login shell anyway. --Nanderty (talk) 23:06, 17 January 2024 (UTC)

Adding something along these lines, as a suggestion rather a requirement, seems reasonable to me overall. (Although one possible issue with this, based on my experiences with X / WMs / compositors over the years, is that if for some reason the GUI session ends up in some unusable state, i.e. hasn't just crashed/exited and returned control to the console, the user will need to log in on a different console, as a different user, in order to fix things.) i'd just like such an addition to note that such code would work for users of other shells as well: zsh users can put it in ~/.zprofile, dash users can put it in ~/.profile, etc.

-- Flexibeast (talk) 12:55, 19 January 2024 (UTC)

I think this idea of yours is good, but checking these variables has issues: $WAYLAND_DISPLAY seems to only be exportet to programms ran from Hyprland, but not in another login-shell, thus being allways evaluated positive. $XDG_VTNR is only exported by systemd, it doesn't work on OpenRC. On my PC at least, the above doesn't work at all. Do you have another idea for checking if a compositor is active for a user, other than definging variable in ~/-bash_profile or similar?

-- Nanderty (talk) 21:28, 30 January 2024 (UTC)

Sorry, i'm not sure i follow. Yes, WAYLAND_DISPLAY will only be set by programs inheriting the environment of the compositor process, i.e. child processes of the compositor process. Are you wanting to make sure that only one compositor process is ever running? If so, then you could use pgrep(1) (part of sys-process/procps, which is included in @system) to check if there's an existing compositor process.

-- Flexibeast (talk) 23:31, 30 January 2024 (UTC)

Now I see, that's required so that not every terminal emulator opened tries to start Hyprland, since its in ~/.bashrc and by moving the code to ~/.bash_profile, the check for WAYLAND_DISPLAY could be dropped, right? Concerning the second check for XDG_VTNR, did I understand correctly that it's purpose is to not start another compositor if one is "incorrectly" running (Black screen, hang, ...), when logging into a different console to resolve that issue? In this case I think using pgrep(1) would be a better solution, since XDG_VTNR is only set by systemd, but wont work on OpenRC. What do you think?

-- Nanderty (talk) 09:10, 31 January 2024 (UTC)

The 'right' thing to do depends on the use-case. Does someone only want there to be one instance of specific compositor running on their system at any time (e.g. "Don't ever run any compositor other than Hyprland, and never more than one instance of Hyprland at a time")? Do they want to make sure only one instance of any given Wayland compositor is running at a time (e.g. "It's okay to start a Hyprland session if there's no other Hyprland sessions are running, but starting any other Wayland compositor is fine")? Do they not care about any of the preceding, and just want to want to start whatever compositor by logging in on one virtual console, regardless of what other compositor processes are already running? And do they only care about dealing with situations in which a particular compositor isn't working, or do they also want to be able to try out others compositors (e.g. Sway) while still running their usual compositor? Regarding the XDG_VTNR environment variable: i've only learned about that variable via this discussion (i don't use systemd myself), so i can't comment on that - as an XDG_* variable, i presume that it's not intended for systemd use only, but i don't know what software does and doesn't make use of it. And finally, the most appopriate place for the logic can vary depending on the specific shell one is using - for example, i don't use Bash, but Zsh, and i make use of the `.zlogin` file to do various bits of login session setup.

-- Flexibeast (talk) 11:15, 31 January 2024 (UTC)

I agree with you that the 'right' is use-case dependant. But I would assume that the purpose of such a section in the Gentoo Wiki is to be a sane default newer users of Gentoo/Hyprland use. An internet search will bring up that XDG_VTNR is intended for and used by systemd. This Gentoo Wiki Article: X without Display Manager suggests the use of XDG_VTNR with systemd but not with OpenRC. The reason I proposed adding a pgrep(1) check before starting the compositor was your reasoning in your first answer about hung up compositors which require a switch to a different console to be fixed. In this console you probably dont want to start your broken compositor again, as it might hang up again and block this console too. So my proposal would be to just write the following:

FILE ~/.bash_profileLaunch Hyprland after logging into a TTY

dbus-run-session Hyprland

This example is for bash, for zsh put it in ~/.zprofile.

This should be a sane default that works anywhre and can be build upon when the use-case demands it.

-- Nanderty (talk) 13:49, 31 January 2024 (UTC)

Sure, i have no objections to putting that in; other people can add text about where to put such a call for other shells (fish, ksh, dash, etc.). As an aside: i've done more research on XDG_VTNR, and it's certainly not only for use on systemd-based systems; elogind, which is logind extracted for use outside systemd contexts, and which i run myself, uses it - cf. e.g. this line in pam_elogind.c.

-- Flexibeast (talk) 01:45, 1 February 2024 (UTC)

Interesting, thank you!

-- Nanderty (talk) 07:59, 1 February 2024 (UTC)