Arch Linux

jbromley

Member

From: Pasadena, CA

Registered: 2007-02-04

Posts: 268

slim session selection [SOLVED]

Hello all,

I am having a small problem with slim session selection and I was wondering if anyone else has seen this problem. I have the following in my /etc/slim.conf file:

# 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 ion3,ratpoison,kde

My .xinitrc is taken directly from the slim sample. Here is my .xinitrc:

# the following variable defines the session which is started if the user
# doesn't explicitely select a session
DEFAULT_SESSION=twm

[ -f /etc/X11/xinit/xinitrc ] && sh /etc/X11/xinit/xinitrc

# Play a sound
ogg123 -q -d alsa /opt/kde/share/sounds/KDE_Startup_1.ogg &

# Set the background
[ -f ~/.fehbg ] && . ~/.fehbg

# Set up xbindkeys
xbindkeys &

case $1 in
    ion3)
        exec ion3
        ;;
    ratpoison)
        exec ratpoison
        ;;
    kde)
        exec startkde
        ;;
    *)
        exec ${DEFAULT_SESSION}
        ;;
esac

According to the slim.conf comment, ion3 should be the default session and should be selected if I log in without explicitly selecting a session with F1. However, if I log in without hitting F1 to select the ion3 session, I get the fallback session. It seems that slim is not passing a session parameter to .xinitrc. I always must hit the F1 key to select a session.

Of course, I can easily solve this by making my * case just run my default session, but I ask since it seems like it should be something easy enough to fix in slim and I was considerning doing it. I just wanted to make sure it was a really problem and not just my problem.

Thanks and regards,
Jay

Last edited by jbromley (2007-10-22 07:56:46)

jbromley

Member

From: Pasadena, CA

Registered: 2007-02-04

Posts: 268

Re: slim session selection [SOLVED]

I checked the code. It was a small bug that didn't properly initialize the current session variable when the sessions configuration was read. I fixed it.