?

Log in

No account? Create an account
Xmonad and KDE on kubuntu feisty - totherme [entries|archive|friends|userinfo]
totherme

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Xmonad and KDE on kubuntu feisty [May. 7th, 2007|12:58 pm]
totherme
[Tags|, , , , , ]

I've not been spending nearly as much time as I'd like to on #haskell recently, so I almost managed to completely miss the xmonad phenomenon. Luckily for me, dons was good enough to write about it, so I haven't missed out completely.

Last year, I spent a few months running wmii - which was fantastic. Since then I've been playing around with Gnome and KDE, which have advantages like konqueror (as a file manager - I prefer FF as a browser), amarok and knetworkmanager. I have been kinda missing the dynamic window management model though - so obviously I wanted to try out xmonad.


I pulled the source from the darcs repo rather than downloading the "stable" tarball, because my experiences playing around with lambdabot had convinced me that the #haskell guys tend to keep their bleeding edge development repos as stable as many packaged binaries from elsewhere (so long as you have the latest dev tools on your system to build with, that is - which I would like to ^_^). Now this is fairly standard boring stuff, but I thought it worth mentioning in passing, because the obvious thing didn't work right away. xmonad (as mentioned in the readme) has some hackage dependancies which you have to satisfy before anything'll build. This is simple enough - you just download the packages mentioned from the URLs listed, and it should all work - but one of them (X-11-1.2) didn't build:

gds@air:~/hackage/X11-1.2$ ls
cbits  config.mk.in  configure  configure.ac  Graphics  include  LICENSE  Setup.hs  X11.buildinfo.in  X11.cabal
gds@air:~/hackage/X11-1.2$ runhaskell Setup.hs configure
Configuring X11-1.2...
configure: /usr/bin/ghc-pkg
configure: Dependency base-any: using base-2.0
configure: Using install prefix: /usr/local
configure: Binaries installed in: /usr/local/bin
configure: Libraries installed in: /usr/local/lib/X11-1.2/ghc-6.6
configure: Private binaries installed in: /usr/local/libexec
configure: Data files installed in: /usr/local/share/X11-1.2
configure: Using compiler: /usr/bin/ghc
configure: Compiler flavor: GHC
configure: Compiler version: 6.6
configure: Using package tool: /usr/bin/ghc-pkg
configure: Using ar found on system at: /usr/bin/ar
configure: No haddock found
configure: No pfesetup found
configure: Using ranlib found on system at: /usr/bin/ranlib
configure: Using runghc found on system at: /usr/bin/runghc
configure: No runhugs found
configure: No happy found
configure: No alex found
configure: Using hsc2hs: /usr/bin/hsc2hs
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for X... no
configure: creating ./config.status
config.status: creating config.mk
config.status: creating X11.buildinfo
config.status: creating include/HsX11Config.h
gds@air:~/hackage/X11-1.2$ runhaskell Setup.hs build
Setup.hs: Package X11-1.2 can't be built on this system.
gds@air:~/hackage/X11-1.2$                          


A quick google revealed the problem in an IRC log - my system (a default kubuntu feisty install, with a couple of things like GHC added after) didn't have the X11 development headers installed. I had a quick look (using the KDE prettification of the package manager - adept) for anything obviously called "X11-headers" or "X11-devel", but saw nothing. Rather than spend time searching, I decided to just click on a couple of things that looked like they had a lot of development dependancies, and hope that the package manager would install what I wanted while it resolved them. The packages I installed were called "libxmu-headers" and "libxmu-dev". I may have gotten away with just libxmu-headers, but I forgot to run "runhaskell Setup.hs configure" before trying "build", and so blindly got the same error message as before. Anyway, after installing those two packages, doing configure, build and install worked fine - though there were a load of warnings during the build stage. They looked pretty harmless, so I ignored them. I have so far suffered no nasal daemons as a result. There were similar warnings in building the mtu package.

When I ran configure on the "X11-extras" package, I got the warning:
WARNING: Xinerama headers not found. Building without Xinerama support


...so I installed the ubuntu package "libxinerama-dev", and retried. That sorted everything fine :)

Tangent:
Every time I installed anything from hackage during this process, I searched with adept to make sure that there wasn't already an ubuntu package that would likely make my life easier in the long run. Wouldn't it be great if hackage could be accessed as an ubuntu package repo? Or a debian repo, or whatever. I know that there's some froody "haskell layer" that the gentoo guys can put over their package manager to get stuff like this with the interface they usually use, but a debian one would be nice too. In fact, it would be really nice if hackage could present itself to any distro's package management system - if all the interfaces were well defined... I realise that to do this properly just for ubuntu would mean someone trawling through all the packages in hackage and noting down what debian/ubuntu packages they all depend on, and that this isn't likely to happen any time soon - but hey, I'm allowed to dream :)

Anyway - dependancies aside, the build was simple - I had a binary ready to run in ~/bin



Something's changed in the last few months though - I'm now doing most of my work on a laptop, rather than a desktop. This means I need to have easy access to battery information, and I need to be able to quickly and easily connect to any wireless networks that happen to be around. KDE does this wonderfully - and I've also gotten to quite like amarok ;) I'd rather not give up these luxuries...

There are better solutions - one of which I'll come back to in a mo, but the first thing I wanted was something quick that worked, involved xmonad, and let me keep using knetworkmanager, etc.

So, I opened up .bashrc and added:
export KDEWM=~/bin/xmonad


I was quite surprised to find how well this worked :) On logging in to X, with this new setting, I saw something like this.


So, the KDE systray isn't working - I guess it needs the window manager to pass it the windows it's supposed to manage - and the kicker is being managed like a window rather than being left to its own devices to place itself at the bottom of the screen.

What I wasn't expecting to work, was these things.


But they do! :) See the notification in the top-left? Those work fine - don't get messed about by the WM at all. This means I get friendly warnings before my power dies, and neat little track name notifications when I'm playing music :)



I could ditch KDE altogether fairly quickly, I think. Most of the things I'd miss can be provided by dmenu, and a couple of command line invocations like "date" and "acpi -b" (though I might need to tweak something in the xmonad source to free up the screen real estate that dmenu would claim, but that doesn't look hard). There's even a dmenu ubuntu package, so that's lovely :)

I don't want to do quite that though, because I'm so addicted to knetworkmanager. I think maybe my ideal setup at the moment would be xmonad, dmenu (with a clock, maybe a couple of buttons for frequently used apps and a battery meter on it) plus a systray of some kind, into which I could put knetworkmanager, klipper and amarok. Apparently the little mini-window things that go into systrays are implemented in X as a special kind of window - which is why they're handled as windows by xmonad. Maybe all that's required is to decide exactly what to do with them, and tell xmonad about the mini-window flag? Dons was good enough to talk us all through the data structure behind xmonad in his recent blog entry, and he said that next time he'd tell us about the IO... So perhaps that'll give me all the knowledge I need to hack together an xmonad systray...?
linkReply

Comments:
From: (Anonymous)
2007-07-23 10:53 am (UTC)

Have you found anything?

I'm in a very similar situation. I'm a long time KDE user and just heard about xmonad, which sounds really interesting.

I might take it for a test drive, but I'm not ready to abandon some KDE software that uses the systray (especially knetworkmanager). Did you find a solution yet?
(Reply) (Thread)
[User Picture]From: totherme
2007-07-23 01:14 pm (UTC)

Re: Have you found anything?

I'm still running the darcs version of xmonad as the KDE window manager. It works quite well for me. I don't have my systray apps available at a glance in a systray on every desktop, but I'm fairly happy with them all sitting on desktop 9, being managed like windows.

I keep meaning to experiment with setting kicker up in the xmonad "gap", so it'll work as a toolbar. Haven't run down that tuit yet though ;)
(Reply) (Parent) (Thread)
From: (Anonymous)
2007-09-05 07:56 am (UTC)
Try xystray
(Reply) (Thread)
From: (Anonymous)
2007-10-02 08:28 pm (UTC)

Trayer...

Install it:
sudo apt-get install trayer

Then, in your ~/.xinitrc:
trayer &

My config is:
trayer --edge bottom --align right --widthtype request --heighttype request --SetDockType true --SetPartialStrut false --expand true &
(Reply) (Thread)
[User Picture]From: totherme
2007-10-03 08:12 am (UTC)

Re: Trayer...

Sounds cool - thanks :)
(Reply) (Parent) (Thread)