fvwm unable to initialize in Kubuntu 8.10...

[Constantinos Maltezos]

On Saturday 31 January 2009 1:21:28 am Joe(theWordy)Philbrook wrote:
> Well since kde4 didn't seem to use the xorg.conf I took a chance that
> any differences in the one that Hardy's installer wrote for this very
> same machine wouldn't mess anything up. So I copied it to my Intrepid
> installation. Then I tried the "startx fvwm" But it didn't quite work.
> The xserver doesn't get far enough to switch the focus from the virtual
> console before it terminates... (I forgot the error message)

If you ever get the message again, I'd be curious to know what it is.

> However another response to this thread suggested that startx would
> use an ~/.xinitrc file. And included an example of what needs to be in
> such a thing. I didn't seem to need one to get kde with startx. But
> when I made an .xinitrc that pointed at fvwm startx began booting
> fvwm by default. (that is "startx" not "startx fvwm") If I want to
> return to kde all I need to do is rename the ~/.xinitrc file before
> running startx... Though I suppose it might work to leave it
> configured for fvwm and try using startkde instead of startx at the
> command prompt...

Are you saying that fvwm works when you put it in .xinitrc?  If so, how 
strange that it wouldn't work the other way, as well.

By the way, I don't think startkde can be used the way you're saying.  If it's 
the same as it used to be, it's meant to be run while another window manager 
that works with KDE (like WindowMaker and blackbox, not fvwm unless they've 
added support) is running.  Then it loads desktop icons and that sort of 
thing, but leaves window management and things like desktop background to the 
window manager.  I don't recall what it does for desktop right clicking.  You 
could, though, make a shell script for KDE that looks like this:

#!/bin/sh
mv .xinitrc .xinitrc.backup
startx
mv .xinitrc.backup .xinitrc

Maybe name it kde.sh or kdestart (not just kde because there's already an 
executable by that name) and do chmod +x to it.  You'll have to specify the 
path with ./ when you run it unless, like me, you add a bin directory to your 
home directory and add it to your path in .bashrc and stick the file in there.  
But that's usually not the greatest of ideas.  I like it though, because I 
have a bunch of shell scripts that I use that I don't want to make available 
to the whole system.