Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generated xsession script shouldn't simply start window manager and then start desktop manager #82074

Open
poscat0x04 opened this issue Mar 8, 2020 · 3 comments · May be fixed by #102322
Open

Comments

@poscat0x04
Copy link
Contributor

poscat0x04 commented Mar 8, 2020

Describe the bug
Right now the generated xsession script simply starts the window manager then starts the desktop manager, this is not ideal for the following reasons:

  1. If spawned separately, the processes spawned by the window manager will not enjoy the environment variables set by the DM, which is needed for app themes, etc.
  2. It is fundamentally the DM's responsibility to swap out its own window manager for an external window manager and every DM does it differently, for example KDE takes an environment variable KDEWM where gnome takes a command-line argument. So I think the function that generates xsession script (xsession, in this case) should be defined in the DM's module instead of a top-level module (you could, but you'll need to distinguish DMs so that's essentially the same (something something expressions problem)).
@poscat0x04
Copy link
Contributor Author

For some DMs it's not even possible to use an external WM.

@poscat0x04
Copy link
Contributor Author

I recommend adding two additional attributes to DMs, the first is whether the DM is able to use an external WM, the second is a function that takes a WM and returns a string (the xsession script)

@stale
Copy link

stale bot commented Sep 5, 2020

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 5, 2020
@poscat0x04 poscat0x04 linked a pull request Nov 1, 2020 that will close this issue
10 tasks
@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Sep 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant