2011-08-13 18:09:32 +02:00
|
|
|
#+title: My StumpWM setup
|
|
|
|
|
#&summary
|
|
|
|
|
How I've set up StumpWM on Trisquel
|
|
|
|
|
#&
|
2013-02-08 16:47:53 +01:00
|
|
|
#+license: wtfpl
|
2013-02-11 21:55:34 +01:00
|
|
|
#+startup: showall
|
2011-08-13 18:09:32 +02:00
|
|
|
|
|
|
|
|
* My StumpWM setup
|
|
|
|
|
|
2013-02-11 21:55:34 +01:00
|
|
|
GNOME
|
|
|
|
|
|
2011-08-13 18:09:32 +02:00
|
|
|
I use StumpWM instead of e.g. Gnome. StumpWM is a tiling window manager, which
|
|
|
|
|
means that it's a good window manager.
|
|
|
|
|
|
2011-08-13 23:55:57 +02:00
|
|
|
** The setup
|
2011-08-13 18:09:32 +02:00
|
|
|
|
2011-08-13 23:55:57 +02:00
|
|
|
I just added a file ~stumpwm.desktop~:
|
2011-08-13 18:09:32 +02:00
|
|
|
#+BEGIN_SRC
|
|
|
|
|
[Desktop Entry]
|
|
|
|
|
Encoding=UTF-8
|
|
|
|
|
Type=XSession
|
|
|
|
|
Exec=stumpwm
|
|
|
|
|
TryExec=stumpwm
|
|
|
|
|
Name=StumpWM
|
|
|
|
|
Comment=Stump window manager
|
|
|
|
|
#+END_SRC
|
2011-08-13 23:55:57 +02:00
|
|
|
to ~/usr/share/xsessions/~, and then I could login to StumpWM via GDM.
|
|
|
|
|
|
|
|
|
|
** Links
|
|
|
|
|
|
|
|
|
|
+ [[http://stumpwm.antidesktop.net/][StumpWM]]
|
|
|
|
|
+ [[https://gitorious.org/nqpz-config/nqpz-config/blobs/raw/master/home/.stumpwmrc][My .stumpwmrc]]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
** Old problems
|
|
|
|
|
|
|
|
|
|
/I have fixed these problems. They remain here for historical reasons only./
|
|
|
|
|
|
|
|
|
|
I never had any problems with StumpWM until I upgraded to Trisquel 4.0 and
|
|
|
|
|
Trisquel 4.5, after which StumpWM irregularly threw errors such as:
|
|
|
|
|
#+BEGIN_SRC
|
|
|
|
|
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying
|
|
|
|
|
GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
|
|
|
|
|
#+END_SRC
|
|
|
|
|
and also some fatal X errors which killed StumpWM and all its running
|
|
|
|
|
programs. This naturally annoyed me. I soon realized that it had nothing to do
|
|
|
|
|
with Trisquel, it was just that dependencies on things like D-Bus was getting
|
|
|
|
|
on StumpWM's nerves. I had always used an Xsession file to login to StumpWM,
|
2011-08-13 18:09:32 +02:00
|
|
|
but clearly, this wasn't good enough. Whenever I ran the default gnome-session
|
|
|
|
|
and whatever window manager was associated to that, there were no problems. And
|
|
|
|
|
while in gnome-session, I could always run:
|
|
|
|
|
: stumpwm --replace
|
|
|
|
|
to replace metacity or whatever with StumpWM. Except for an annoying
|
|
|
|
|
gnome-panel and Gnome taking over some of my keybindings, this worked
|
|
|
|
|
alright. The best thing was that when the fatal X error occured, only StumpWM
|
|
|
|
|
was killed --- all windows were maintained. This made me realize that one could
|
|
|
|
|
create a script which starts a new StumpWM instance whenever an old StumpWM
|
|
|
|
|
crashes, to create the illusion of a continually running StumpWM.
|
|
|
|
|
|
2011-08-13 23:55:57 +02:00
|
|
|
*** Solution
|
|
|
|
|
|
|
|
|
|
I compiled StumpWM from git with SBCL instead of CLISP. Now it doesn't crash.
|
|
|
|
|
|
|
|
|
|
*** Original solution
|
2011-08-13 18:09:32 +02:00
|
|
|
|
|
|
|
|
I added this to my ~.profile~:
|
|
|
|
|
#+BEGIN_SRC sh
|
|
|
|
|
if [ "$DISPLAY" ] ; then
|
|
|
|
|
pkill stumpwm
|
|
|
|
|
# Restart StumpWM when it crashes
|
|
|
|
|
while [ 1 ] ; do
|
|
|
|
|
stumpwm --replace
|
|
|
|
|
pkill stumpwm
|
|
|
|
|
done
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# Since StumpWM will continue forever, this .profile file will block
|
|
|
|
|
# gnome-session from loading misc. crap.
|
|
|
|
|
#+END_SRC
|
|
|
|
|
|
|
|
|
|
You may also have to edit ~gnome-panel~ out of
|
|
|
|
|
~/desktop/gnome/session/required_components~ in ~gconf-editor~.
|
