metanohi/site/writings/stumpwm.org

83 lines
2.6 KiB
Org Mode
Raw Normal View History

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~.