Automatic discovery of DE/WM by login managers in the NixOS module

berbiche commented 3 years ago

Language

While most people reading this are going to be familiar with the language, I will nonetheless introduce the vocabulary.

DE stands for display environment and is responsible for managing the session (automatically starting applications, power management, display configuration, device plugging/unplugging, etc.).

WM stands for window manager and is responsible for opening windows and placing them on the desktop.

A login manager is the prompt that allows you to enter your credentials and to login into your computer. A login manager can optionally start a graphical session like a DE or a WM.

A DE usually includes a WM e.g. Gnome, KDE or XFCE, because a DE is not sufficient. Some DEs also supporting plugging a different WM like kde + i3 or xfce + i3.

A WM is something like i3, Sway, openbox, xmonad, awesome, etc. All they do is starting scripts and managing window positioning (including panels, status bars, trays, etc.).

Description

The NixOS/nixpkgs#68371 PR seems like a good option. With that you'd choose the "xsession" desktop for HM and still be able to choose other desktop managers if you like.

Basically I would still like to be able to select the desktopManager/desktopEnvironment from my displayManager, but I'd also like to be able to use home-manager's xsesssion/graphical session. Is this possible?

Originally posted by @IvanMalison in https://github.com/nix-community/home-manager/issues/862#issuecomment-879215684

This is something that has been on my mind for a few months now and was recently requested in a different issue.

With the NixOS module, configuration for graphical environments should expose the sessions to display managers / login managers.

This would be a first step for #2122 and provide a different path for #2123.

Technicalities

Home Manager

On the HM side, we would need an (internal) option to expose configured sessions. Any system built around HM would then be free to expose these sessions.

{
  lets-not-bikeshed-on-the-option-name = attrsOf <wm name> {
    script = a path or a package or a multiline string;
    # I don't know whether this is used by anything but it could be useful
    icon = optional (path or string);
  };
}

NixOS

On the NixOS module side, there are two solutions:

Setting up sessions through services.xserver.displayManager.session: https://github.com/NixOS/nixpkgs/blob/6b940846e99cedd10eafbc301e467972ade1afec/nixos/modules/services/x11/display-managers/default.nix#L219-L246
Creating {wayland-sessions,xsessions}/$USER-<wm-name>.desktop files and adding them to services.xserver.displayManager.sessionPackages (I think this also requires derivation.passthru.providedSessions but I'm not sure).

We would add one new boolean option to toggle the automatic exposure of WMs to NixOS, defaulting to true. We would also expose some library functions to transform the HM sessions in NixOS sessions (which we would also use internally). This would give users the option to filter the exposed sessions while having no cost to us.

Pros

Discoverability of user sessions
Easily change between desktops by logging out
Managing everything from the HM side!

Cons

This would expose every wm+de to every user with the boolean option. I don't think this poses much of a privacy risk because user files are not exposed.
It could set a precedent and lead to more options in the NixOS module.

CC

@nix-community/home-manager

People that contribute to these kinds of things in NixOS/HM: @Vonfry @SebTM @colemickens @ncfavier

Rosuavio commented 3 years ago

Can I just say that I very much so want this!

As a user of different parts of the nix echo system, it feels the echo system does a really well with allowing a layering approach, NixOS on the bottom, then the user env, and lastly nix-shells. And for the most part, boundaries between these layers are well defined and have a lot of thought that goes into them. But I think this has become a big corner case.

From what it seems, this pain point stems from this kind of thing traditionally not being very viable around the rest of the Linux echo system. This resulted in login managers not really putting much focus into allowing users to load session configuration from inside there user dirs. And it seems that, as a result when NixOS modules were built around these login managers the lack of user defined sessions came with them.

I don't know if there would need to be work done on login managers to help enable this, but there was discussion around this kind of enablement in sddm. https://github.com/sddm/sddm/issues/916

ncfavier commented 3 years ago

Sounds good, but how would this help solve #2112?

berbiche commented 3 years ago

Sounds good, but how would this help solve #2112?

I don't remember what I was thinking at the time for #2112 and now I don't think this would alleviate the problem.

stale[bot] commented 3 years ago

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

colonelpanic8 commented 3 years ago

@berbiche isn't this fixed by @Vonfry 's change: https://github.com/nix-community/home-manager/pull/2123

SebTM commented 3 years ago

Could you give an example how this would help in the case of defining the desktop-manager in home-manager? I don't really understand how to use it to be honest...

SebTM commented 3 years ago

I tried it with several options/combinations even switched from lightdm to gdm and without:

{
    services.xserver.desktopManager.session = [
        {
            name = "home-manager";
            start = ''
                ${pkgs.runtimeShell} $HOME/.xsession &
                waitPID=$!
            '';
        }
    ];
}

in configuration.nix it doesn't work. (Source: https://discourse.nixos.org/t/opening-i3-from-home-manager-automatically/4849/8)

If I understand the initial issue correct/what I would consider as a real win especially for beginners would be setup/configuring XServer/display-manager in NixOS and Desktop Environment e.g. i3wm in home-manager which works out-of-the-box :)

stale[bot] commented 2 years ago

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot to close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

stale[bot] commented 2 years ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

SebTM commented 1 year ago

not stale, but not enough permission to remove the label :v:

colonelpanic8 commented 1 year ago

@SebTM You're setting an explicit start with the desktop manager session. I'm not really sure what you're expecting but I would regard this as fixed.

This issue is stale, and its already been resolved as far as i can tell.

ckiee commented 1 year ago

@IvanMalison Personally I still have a NixOS services.xserver.desktopManager.xterm.enable = true; in my config so NixOS reads home-manager's ~/.xsession. (as described in https://github.com/nix-community/home-manager/issues/3818)

Are you not experiencing the need for this NixOS option or a different desktopManager? What happens when your home-manager DM(/WM) crashes? I can't rebuild right now, but I'm not aware of anything changing.

Please don't dismiss a detailed bug report so lightheartedly.

colonelpanic8 commented 1 year ago

@ckiee Maybe I'm completely missing what this issue is about. I'd be a bit surprised if that were the case though, the first thing in the description is a quote from me (attributed by name).

Look at the title of the issue:

"Automatic discovery of DE/WM by login managers in the NixOS module". Can you precisely describe the sense in which this is not working? I literally use this feature every day without any issues or special configuration of my home-manager.

also w.r.t "Please don't dismiss a detailed bug report so lightheartedly." I AM THE ONE who essentially reported this originally as it is my quote that is used as the primary description of the issue.

Personally I still have a NixOS services.xserver.desktopManager.xterm.enable = true; in my config so NixOS reads home-manager's ~/.xsession. (as described in #3818)

Seems like there's an issue for that in oh, oh yeah #3818 . How is that related to the original purpose of this issue?

colonelpanic8 commented 1 year ago

@SebTM @ckiee It might help if you actually read a bit more about what is going on here. In particular:

https://github.com/nix-community/home-manager/pull/2123#issuecomment-870227107

Could you give an example how this would help in the case of defining the desktop-manager in home-manager? I don't really understand how to use it to be honest...

Not what this issue is about. This issue is about making the default nixos desktopManager be able to actually use wms and with the default home manager session without it being overriden.

ckiee commented 1 year ago

I apologize for my last message, I think I was too tired to properly express myself - I did not mean to be aggressive. :purple_heart:

Anyway, I've re-read this issue and skimmed the quoted one you linked, and I'm not sure how this issue has been resolved? I don't see the workaround grepping in the HM repository and it doesn't allow for DE/WM switching, which is what I read this one to be about.

I still need NixOS services.xserver.desktopManager.xterm.enable to use the home-manager'ed i3wm from my display manager, which is the scope of this issue; #3818 is about making the HM mechanisms for this nicer, not making them work.

At the time, in order to find out about services.xserver.desktopManager.xterm.enable I had to ask rycee in the home-manager chatroom, which is not automatic at all. If I don't set this option, lightdm gives me a "Failed to start session" popup under the password field.

So I don't think this should be closed, because, as far as I know, we still don't set any system-wide/NixOS options from the HM module to configure the Xserver, and I'm not sure if we should.

stale[bot] commented 1 year ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

kngrektor commented 10 months ago

I'd like to add that this a problem for Wayland as well and there's no xsession equivalent. Seems like login managers only check /usr/share/wayland-sessions by default and supporting per user sessions sounds like a pain.

stale[bot] commented 7 months ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

ckiee commented 7 months ago

Still not stale afaik

stale[bot] commented 4 months ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

SebTM commented 4 months ago

Not stale 🙏🏻

nix-community / home-manager