Quoting from upstream slim.conf: " # Available sessions (first one is the default). # The current chosen session name is replaced in the login_cmd # above, so your login command can handle different sessions. # see the xinitrc.sample file shipped with slim sources sessions xfce4,icewm,wmaker,blackbox " Also, in version slim-1.3.2-r2 the following is added by a gentoo patch: " +# Alternatively, read available sessions from a directory: +sessiondir /etc/X11/Sessions " As the comment on upstream config says, the first session loaded should be default, but this is not what happens. The default sessions is always an empty string. If the user presses F1, it cycles throught the avaiable sessions, and it is not possible to select an empty session. The selected session (or the an empty string if user didn't press F1) is passed to login_cmd script and is up to it what to do if it receives an empty string. In the case of Gentoo, this is script is "/usr/share/slim/Xsession", which execs xterm. I see this as an upstream bug, as the default session is not the first, as the documentation suggest and if user presses F1, it cannot select the empty session again, which suggest that opening xterm is an side effect of the bug (fall back case in the script), not the intented behavior, as the user cannot deliberate choose this option. I personally think this is annoying, as I have to press F1 every time and I can't define a default session. Reproducible: Always Steps to Reproduce: 1. Start Slim login manager. 2. Login without press F1. Actual Results: You get an xterm session instead of the default session that should be the first on the list. Expected Results: You should get your default session, the first one on the list defined by "sessions" config option or one of the sessions defined in the directory pointed by "sessiondir" option. I went to the source code to understand what is happening, and it really defines the empty string as the default value, and this empty string is not part of the vector that stores the list of sessions. So, if user don't press F1, it get an empty string as the choosen session, if it presses F1, it starts cycling through the sessions list that do not include an empty string, so it cannot select this session again. I am attaching a patch that fix this issue, it changes just the line that defines de initial current session on the panel to empty string. Changed from the empty string to the first session of the sessions list.
Created attachment 251847 [details, diff] Fix bug 342523, wrong default session
Created attachment 251855 [details, diff] Ebuild change do include proposed bugfix patch for #342523
The new Xsession support in slim was designed to match similar session selection in the other WM's. The "default" session, ie, what the XSESSION environment variable is set to, or your user's ~/.xsession script, is selectable via the "Xsession" option which (if the sessiondir config option remains set) is on the list of sessions that you can see via [F1]. If no option is specified at all then the script looks for the availability of a user's ~/.xsession and/or whether or not the XSESSION environment variable is set, and uses that. [ slim currently _doesn't_ support default sessions specified in /etc/rc.conf, and that is because that support has been removed from xinit and baselayout, but a fixed baselayout (1.2.14 , iirc) hasn't been marked stable yet. The proper method is now to set the XSESSION environment variable globally in /etc/env.d/90xsession ] At the time this script was written (for 1.3.2), there didn't seem to be a way to manage the 'sessions' config option for choosing the default (first) value. I will look at your submissions to see if I can integrate this, although I would personally recommend setting your default session via ~/.xsession , ~/.bash_profile or /etc/env.d/90xession and then slim's Xsession-chooser script should allow you to work as you want.
(In reply to comment #3) > The new Xsession support in slim was designed to match similar session > selection in the other WM's. > > The "default" session, ie, what the XSESSION environment variable is set to, or > your user's ~/.xsession script, is selectable via the "Xsession" option which > (if the sessiondir config option remains set) is on the list of sessions that > you can see via [F1]. > > If no option is specified at all then the script looks for the availability of > a user's ~/.xsession and/or whether or not the XSESSION environment variable is > set, and uses that. > > [ slim currently _doesn't_ support default sessions specified in /etc/rc.conf, > and that is because that support has been removed from xinit and baselayout, > but a fixed baselayout (1.2.14 , iirc) hasn't been marked stable yet. The > proper method is now to set the XSESSION environment variable globally in > /etc/env.d/90xsession ] > > At the time this script was written (for 1.3.2), there didn't seem to be a way > to manage the 'sessions' config option for choosing the default (first) value. > I will look at your submissions to see if I can integrate this, although I > would personally recommend setting your default session via ~/.xsession , > ~/.bash_profile or /etc/env.d/90xession and then slim's Xsession-chooser > script should allow you to work as you want. > Hi Ian, thanks for commenting. I will try to explain better (sorry for my english). What I am talking about is *not* about the script, the xsession-chooser script, but about the Slim itself. About what I am convinced that is a bug in Slim itself. Slim's documentantion says that Slim will pass the session selected by the user to the script pointed by login_cmd option. This is independently of what session script is handling this parameter. The thing is, that the doc also says that, if the user do not select a session, the first one is the default. But what actually happens is that, in case user do not select a session by pressing F1, the first one (default) is not passed to script. I think that if this was intentional, than the user should be able to select this "special session" which screen will pass nothing and let the session script do whatever it thinks it should. But the user can't, once the user presses F1, it cannot goes back and cannot select that "special empty session" ever again. At least, no until restart slim or login and logout. And it doesn't matter if the sessions reconized by slim is the ones explicited on by the option "sessions" on the config file or are the sessions read on the directory especified by the option "sessiondir" on the config file. The code that handles this is the same, and class of the panel that stores the selected session always starts with an empty value (instead of the first session on the list), and the special empty value cannot ever be selected again by the user once it changes it. This what my patch changes, it sets the default session (initial value of the variable) to the first recognized session of the sessions lists, instead of the empty string. I can't recall all the classes name right now, I am at work now, but I can point you to them if you want to take a look as soon as I get home. Sorry if I can't explain it more well or clear, I am still learning english. Let me know if I can be of more help. Regards,
I concurr, there is a bug upstream -- slim is not doing what it documented itself as doing (that is, specifying "" when no session is explicitly chosen, instead of the first on in the 'sessions' list). Functionality-wise, though, I'm not sure if this is actually undesired behaviour; and Gentoo's Xsession chooser script takes advantage of it. I'm also not sure if said behaviour would apply to the (currently undocumented) 'sessiondir' config option. Either way, though, final resolution of this bug will have to be upstream's decision (whether they change the code or the documentation), and i'm forwarding it upwards.
(oops, sorry for the mis-assignment)
(In reply to comment #5) > Functionality-wise, though, I'm not sure if this is actually undesired > behaviour; and Gentoo's Xsession chooser script takes advantage of it. I'm > also not sure if said behaviour would apply to the (currently undocumented) > 'sessiondir' config option. It is the same behavior in both cases. The method that handles 'sessiondir' and 'sessions' config options is the same: Cfg::fillSessionList() at file cfg.cpp, the logic is this: if the config option 'sessiondir' is not empty, scan files in that directory and populate the internal sessions list. After this, if the internal sessions list is still empty, then it reads the config option 'sessions', splitting its value at each comma. The internal sessions list is a vector name 'sessions'. Regardless its content, if it is empty or not, if its content were read from 'sessionsdir' or from 'sessions' config option, the default session is always the same, the empty string, assigned at Panel's constructor, Panel::Panel() at panel.cpp. I agree with you, it is an upstream bug, and I don't know what was the intented behavior, but to me it makes more sense if the "first sessions is default" behavior would apply only in case of 'sessions' config, because in case of 'sessiondir' config, the first one is not easily predictable, as it is read in the filesystem order, not alphabetically.
Ian, what needs to happen here?
From Gentoo, nothing -- upstream (if there still is one) needs to sort this out, to make the design call of whether or not %session is blank if not explicitly chosen.
The proposed patch works for me.
I would like to close this bug, without applying the patch. The reason being that, *if* slim always selected the first option in the list when one isn't explicitly chosen, there would be no way to support the standard "gentoo" way of choosing the session via $XSESSION (as stated in the xorg-config guide). I will update the description in the default slim.conf file, though, to remove the statement regarding the first one being default since this is certainly incorrect.
As of slim-1.3.2-r6 , the config file comments have been changed to reflect what slim actually does. There is a patch upstream that addresses the empty-default-session; if upstream chooses to apply it in the next release then we'll change the comment back.
