nixos/desktop-managers/xterm: Disable by default

[adisbladis]

It's a confusing default for some display managers that will default
to it even when you have defined another display manager.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Notify maintainers

cc @

[Lassulus]

yes! this is a constant annoyance when new people start with nixos and think something is broken, because only xterm shows up after entering the login credentials in the desktopManager.

[worldofpeace]

Is it that xterm in some cases is the value of services.xserver.desktopManager.default even when there's other sessions?

[Lassulus]

it being the default is the core problem, but since xterm is a very user unfriendly desktop-manager, there should be imho no reason to even show this to the user in the default case.

[adisbladis]

Is it that xterm in some cases is the value of services.xserver.desktopManager.default even when there's other sessions?

That is one of the problems, yes.

It's also completely unusable as a desktop-manager so having it enabled by default serves absolutely no purpose.
If you want to use it for some debugging it's just a one-liner config change away to enable it.

[adisbladis]

Another thought: I should add a changelog entry before merging.

[worldofpeace]

I was actually interested why xterm becomes the default desktopManager in certain instances and not others. That sounds like a bug.

[adisbladis]

I was actually interested why xterm becomes the default desktopManager in certain instances and not others. That sounds like a bug.

Is it really a bug? Our DEs do not have an inherent ordering so wouldn't it be up to each individual display manager to choose which one to pick by default?

[worldofpeace]

So it seems, for users like @srhb that rely on xterm DE being default enabled they're unexpectedly greeted with their DM not starting their session. I think the release note could clarify this, but I think maybe it would be intuitive if, when there's no DE or WM and xserver is enabled, we turn on xterm.

[srhb]

I think adding a big fat "WARNING: If you had no explicit desktopManager previously, you will need to add one now!" is definitely a possibility, if not great UX. I'm not sure how to estimate how many relied on the previous behaviour, but I think it's reasonably common in the case where people are using ~/.xsession to do the heavy-lifting -- the previous default just worked for that, even if it's sort of unintuitive once you start thinking about the fact that it was the xterm session taking over.

[srhb]

Sidenote: I think it's probably more common with home-manager users than pure NixOS users.

[worldofpeace]

I think adding a big fat "WARNING: If you had no explicit desktopManager previously, you will need to add one now!" is definitely a possibility, if not great UX

In the note or using warnings in the xserver module?

[srhb]

In the release note. I don't think I would have realized the consequences of this change just by reading the current text. :)

[samueldr]

Would it make sense, and can it be done, to implement an xsession session type, to better convey the intention of the user? Even if, in the end, it is exactly the same as the xterm one, but named xsession.

[worldofpeace]

services.xserver.desktopManager.session actually composes an xsession.
Is that the UI you're thinking of @samueldr?

[samueldr]

Right, I think I understand that any wrapped session will end up using ~/.xsession when it exists.

So, not exactly, but almost. I'm thinking about:

{
  services.xserver.desktopManager.xsession.enable = true;
}

But the implementation could be the same or about the same as the xterm desktopManager. The main difference I can see that would be helpful is launching the terminal or another dialog explaining that ~/.xession should exist when using that session type.

This only ends up being a coat of sugar around the existing infra. Though it ends up being helpful in signalling "I want to use my home directory's ~/.xsession". That is, rather than defining the xsession commands at the system level.

Does this make sense?

[worldofpeace]

Right, I think I understand that any wrapped session will end up using ~/.xsession when it exists.

Correct, and in some cases it can be an "impurity" that causes issues for some users of nixos and our declarative nature. Though that's how an xsession wrapper should be like.

But the implementation could be the same or about the same as the xterm desktopManager. The main difference I can see that would be helpful is launching the terminal or another dialog explaining that ~/.xession should exist when using that session type.

This only ends up being a coat of sugar around the existing infra. Though it ends up being helpful in signalling "I want to use my home directory's ~/.xsession". That is, rather than defining the xsession commands at the system level.

Do you mean an option which the semantics are that it's for "hey 👋️, I just want to use a ~/.xsession".
(does this mean default the wrapper doesn't exec this?)

Perhaps @rycee has an opinion? As noted @srhb said it's common for those users, and I do like drawing from home-manager as an interesting almost experimental module system/UI.

[samueldr]

Do you mean an option which the semantics are that it's for "hey 👋, I just want to use a ~/.xsession".

Yes, that's basically it.

(does this mean default the wrapper doesn't exec this?)

I'm thinking this could be an initial step into making the default wrapper not exec ~/.xsession. Though, I don't think we have to remove that impure "feature" at first.

I'm wondering how we could deprecate the misfeature of launching the xsession script on other sessions in a user-friendly way. I'm thinking the most likely one is to use something akin to xdialog before ~/.xsession is executed for non-xsession sessions, asking the user to switch to an xsession session.

This probably should be moved to a feature issue or something rather than hijacking this PR's comments :).

[srhb]

We may want to open an issue (I can do that) but I definitely consider this a blocker for 19.09. :)

I definitely think that falling back to something like an xsession if nothing else is selected is the right behavior for now. Xterm definitely is a poor name for it, but that's about the only thing wrong with it.

[nbardiuk]

Accidentally found this PR to learn that I need to enable xterm manually.

My setup uses home-manager to configure i3wm and doesn't have any DM enabled explicitly.

So it seems, for users like @srhb that rely on xterm DE being default enabled they're unexpectedly greeted with their DM not starting their session. I think the release note could clarify this, but I think maybe it would be intuitive if, when there's no DE or WM and xserver is enabled, we turn on xterm.

How can we help other users who stumble on this issue so they don't have to search for PRs on github?

[peti]

It appears that this PR has broken my laptop in the sense that I can no longer log in at all (#68360). Since I use neither Gnome nor KDE, xterm is my only session type!

[adisbladis]

I'm tempted to revert for now and leave any improvements for 20.03. Anyone against?

[srhb]

I think that sounds very prudent, giving the timing. 👍

[worldofpeace]

Can we use stateVersion? So it's still default, but for new people it isn't?
Ideally we want users to enable xterm and not just rely on it being enabled default.