-
Notifications
You must be signed in to change notification settings - Fork 19
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
FR: Replace "Session:" label with a session type selector (Wayland, X11 etc) #92
Comments
I forgot to mention how this came into my head, I was thinking about how in #65 there is an edge case where some X11 sessions start the x server and some don't and how this could be addressed by having a separate UI for X sessions specifically, or how something like Gnome might have an X11 and Wayland modes and right now its up to the packagers of the desktop files to make sure those are actually possible to distinguish (xdg file ID being unique + including the type in the These are not issues I have with 1 user and 1 session, so I dont know how relevant it is. I can't imagine someone using the GUI greeter to login into a shell, but oh well, it could actually be a thing. |
IMHO, it seems like it presents too much complexity to an ordinary user, who might just want to open their DE/WM sessions. For more advanced users, they can already type in their session command. The default shell is more of a fallback, and so I wouldn't like to expose it. As for people logging into shells, you're right, I don't think they'd be using ReGreet anyway. So I don't think that we would need to change the UI to accommodate them. As for X11 handling, I just merged #16, which finds out if a session is an X11 session the way LightDM does. In other words, it simply checks if the parent dir is named |
So I poked in the code and it turns out the only way you'd need the default session is if either
Both of those can be mitigated with trivial checks (I did that in my fork, but that would have to be merged after some smaller PRs). This is just a long way of saying the /etc/passwd shell quite useless. |
Good point, got carried away |
Great, so I guess we can close this issue once we merge those checks. |
Closed it because the session selector is out of scope and all this related discussion will be a PR in the future |
Is this something anyone actually wants? Not theoretically, I need this theoretically-just-in-case too, practically is this a thing you want?
Currently regreet has 2 options for selecting a session presented as a dropdown (X11 & Wayland combined) with a secret fallback to the login shell if there are no XDG sessions, and an arbitrary command. This works well enough, but what if the user doesn't have a default shell or they specifically want that, or what if they wanna choose a different shell from
/etc/shells
.This is just an idea, the "Session:" label is replaced with a dropdown that has the following options (ordered by priority, default on startup is the first one):
$XDG_DATA_DIRS/wayland-sessions
$XDG_DATA_DIRS/xsessions
/etc/passwd
/etc/shells
If any of the categories were not found during loading, the option for that would be not be present.
The only issue I can anticipate is with the default shell option. If at least 1 user has it, the option would show up, but then there should be code to handle the username (regardless of it coming from the dropdown or the manual input) not having a default shell.
Handling it is not hard, just stop the user from starting auth or if the UI would in the future allow the user to change the session during auth, just put them in a state like the image below (show notification + not make it look like the auth was discarded)
At the IPC level this is the state between the last auth response (greetd returned suceess) and before start session that actually specifies the command and the ENVs.
Yes, this UI is not in this repo, its from my fork as part of #85, eventually it will be proposed as a set of PRs, I am slowly working on that.
The text was updated successfully, but these errors were encountered: