How to make KDE the default for startx -- :1
SuSE 9.2 with KDE 3.4. Used to be, a second person on my machine could do a text login at the F1 console, run "startx -- :1 and find themselves in a GUI session on F8. That second session type seemed to default to KDE, which is what I normally run when I login via the KDM login. For a couple of months now, startx -- :1 launches an FVWM session, instead of KDE. I'm still running KDE on F7 (started from KDM login), but my wife is losing patience since she would prefer KDE for her session as well. I've been snooping a trail of config files, and haven't seen anything that I recognize as the source of the problem. If I recall, we first noticed it after I installed KDE 3.4. KDE 3.4 itself seems fine. I did a full install, rather than attempting an update. Hints? Pointers? Thanks, Kevin
On Friday 15 April 2005 01:50, elefino wrote:
SuSE 9.2 with KDE 3.4.
Used to be, a second person on my machine could do a text login at the F1 console, run "startx -- :1 and find themselves in a GUI session on F8. That second session type seemed to default to KDE, which is what I normally run when I login via the KDM login.
For a couple of months now, startx -- :1 launches an FVWM session, instead of KDE. I'm still running KDE on F7 (started from KDM login), but my wife is losing patience since she would prefer KDE for her session as well.
I've been snooping a trail of config files, and haven't seen anything that I recognize as the source of the problem.
If I recall, we first noticed it after I installed KDE 3.4. KDE 3.4 itself seems fine. I did a full install, rather than attempting an update.
update vs. full install of KDE? How do you mean? About your problem: the startx script starts the window manager defined by the environment variable $WINDOWMANAGER. If at the command prompt you run echo $WINDOWMANAGER you will see what it's set to. fvwm is what the system defaults to if it can't find the program set by $WINDOWMANAGER (well, it's the second choice, if it can't find kde) as you can see in /usr/X11R6/lib/X11/xinit/xinitrc I believe your problem is caused by a name change (or packaging problem). WINDOWMANAGER is set to 'kde' while the new kde doesn't provide the 'kde' link. I think you can probably solve your problem by running the command ln -s /opt/kde3/bin/startkde /usr/X11R6/bin/kde You can change the system default window manager (and therefore the default value of the $WINDOWMANAGER variable) by editing the script /etc/sysconfig/windowmanager
Am Freitag, 15. April 2005 02:03 schrieb Anders Johansson:
On Friday 15 April 2005 01:50, elefino wrote:
SuSE 9.2 with KDE 3.4. [...]
Hello, same Prob at my Place, after the Upgrade from KDE 3.3.2 to 3.4 on my SuSE 9.1 "startx" from inside a Konsole starts fvwm ...
About your problem: the startx script starts the window manager defined by the environment variable $WINDOWMANAGER. If at the command prompt you run
echo $WINDOWMANAGER
you will see what it's set to.
fvwm is what the system defaults to if it can't find the program set by $WINDOWMANAGER (well, it's the second choice, if it can't find kde) as you can see in /usr/X11R6/lib/X11/xinit/xinitrc
I believe your problem is caused by a name change (or packaging problem). WINDOWMANAGER is set to 'kde' while the new kde doesn't provide the 'kde' link.
I think you can probably solve your problem by running the command
ln -s /opt/kde3/bin/startkde /usr/X11R6/bin/kde
Works for me ... Thanks Michael
You can change the system default window manager (and therefore the default value of the $WINDOWMANAGER variable) by editing the script /etc/sysconfig/windowmanager
On Thursday 14 April 2005 20:03, Anders Johansson wrote:
update vs. full install of KDE? How do you mean?
I just mean that I got rid of 3.3 before installing 3.4. In the past, I used to upgrade from within the current version, then just stop and restart X, but this time I read a few too many accounts of problems with that approach.
About your problem: the startx script starts the window manager defined by the environment variable $WINDOWMANAGER. If at the command prompt you run
echo $WINDOWMANAGER
you will see what it's set to.
fvwm is what the system defaults to if it can't find the program set by $WINDOWMANAGER (well, it's the second choice, if it can't find kde) as you can see in /usr/X11R6/lib/X11/xinit/xinitrc
I believe your problem is caused by a name change (or packaging problem). WINDOWMANAGER is set to 'kde' while the new kde doesn't provide the 'kde' link.
I think you can probably solve your problem by running the command
ln -s /opt/kde3/bin/startkde /usr/X11R6/bin/kde
You can change the system default window manager (and therefore the default value of the $WINDOWMANAGER variable) by editing the script /etc/sysconfig/windowmanager
Thanks for the good, succinct explanation. It's nice when somebody explains something and I actually find the same stuff in the same places. :-) Is there a reason you suggested creating the link, rather than just editing lines in xinitrc? I'm not really good at implications unless they're spelled out, or I trip over them. Kevin
elefino wrote:
On Thursday 14 April 2005 20:03, Anders Johansson wrote:
I think you can probably solve your problem by running the command
ln -s /opt/kde3/bin/startkde /usr/X11R6/bin/kde
You can change the system default window manager (and therefore the default value of the $WINDOWMANAGER variable) by editing the script /etc/sysconfig/windowmanager
Thanks for the good, succinct explanation. It's nice when somebody explains something and I actually find the same stuff in the same places. :-)
Is there a reason you suggested creating the link, rather than just editing lines in xinitrc? I'm not really good at implications unless they're spelled out, or I trip over them.
X doesn't know where KDE or any other window manager might be installed. Therefore it expects a window manager to install at least a link in the X binary directory, and it uses that link to start up the appropriate window manager. The alternative is X would have to search the entire installed base every time looking for your window manager, in case it got moved for some reason (eg an update). Sort of like your mom wanting to be kept informed of where you were when you were a kid. Only this time, someone forgot to tell mom (X) where the kid (KDE) is, and mom isn't going looking
On Saturday 16 April 2005 05:01, elefino wrote:
Is there a reason you suggested creating the link, rather than just editing lines in xinitrc? I'm not really good at implications unless they're spelled out, or I trip over them.
Functionally there's no difference, you could have solved your problem either way. It's just that if I have a choice between editing a script or creating a symlink, I'll go for the symlink. The symlink is the 'correct' solution anyway, since the rpm should have created one, and I suspect the next update will again
participants (4)
-
Anders Johansson -
Darryl Gregorash -
elefino -
Michael Schueller