[Xmonad] how to install?

David Roundy droundy at darcs.net
Sat Apr 14 12:52:33 EDT 2007

On Sat, Apr 14, 2007 at 10:27:12AM -0600, Jason Creighton wrote:
> On Sat, Apr 14, 2007 at 07:09:57AM -0700, David Roundy wrote:
> > On Fri, Apr 13, 2007 at 06:04:46PM -0600, Jason Creighton wrote:
> > > I poked around the cabal docs for a bit, and I didn't see any obvious
> > > way to get cabal to check for the presence of certain headers. Also, if
> > > the headers weren't there, we couldn't really do anything anyway, other
> > > than fail with a friendlier error.
> > 
> > Argh! That seems crazy.  How can cabal not have support for looking for
> > libraries? It's not so hard to write, but this seems like it'd be
> > critical--certainly it'll be critical if we're going to use cabal for darcs
> > (as Eric is in the process of doing).
> I Am Not A Cabal Expert. Please take what I say with a grain of salt. :)
> But it does appear to me that, for right now anyway, the answer is "use
> autoconf or similar":
> http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html#system-dependent

Argh.  I Am Less Of A Cabal Expert, but it seems like the whole point of
using cabal at all is to do our build scripting in Haskell.  (see below)

> > > I wonder if the Xinerama module should be a separate package anyway.
> > > What do you guys think about that?
> > 
> > It could be, but then we'd still depend on the module, unless cabal
> > supports optional package dependencies.  I'd rather have a compile-time
> > check whether xinerama is present, and preferably if it's not present then
> > we should emit a warning (WARNING: compiling without xinerama support!!!)
> > and compile an X11-extras with the same API, but which assumes just one
> > screen.  It doesn't seem like it should be that hard, and reducing the
> > number of libraries required would definitely be a Good Thing.  Most people
> > don't actually have two monitors.
> Yes, that could work. I'm working on doing this with a simple
> "configure" (just a plain shell script, no autoconf (yet?)) script. I'll let
> y'all know how it turns out.

Couldn't this be done in Haskell? It'd be a real shame if cabal doesn't
have sufficient hooks to allow something like this to be written, and it
seems like one ought to be able to write nice Haskell functions to do all
the interesting autoconfish things.

(And no, I don't mean to be a pain...)

> This brings up another minor issue: Right now, Graphics.X11.Xinerama
> exports:
> XineramaScreenInfo data structure
> xineramaIsActive :: Display -> IO Bool
> xineramaQueryExtension :: Display -> IO (Maybe (CInt, CInt))
> xineramaQueryVersion :: Display -> IO (Maybe (CInt, CInt))
> xineramaQueryScreens :: Display -> IO (Maybe [XineramaScreenInfo])
> getScreenInfo :: Display -> IO [Rectangle]
> The xinerama* functions are as direct as possible wrappers around their
> C equivalents. getScreenInfo is a helpful wrapper around
> xineramaQueryScreens that fakes out a single display when Xinerama is
> not active. (That's right: Even if the X11 servers supports Xienrama, if
> it's not currently being used, all the Xinerama-functions fail. Yay.)
> So if nobody objects, I'm going to continue to work on autoconfig magic
> to make a "getScreenInfo" that works even in the face of non-existent
> Xinerama.

This sounds great to me.  But I imagine that at least xineramaIsActive
ought to be very easy to deal with in the absense of Xinerama (always
return True, or False?).  And the others also seem like you could stub them
out in such a way that the behavior of a Xinerama-aware program will be the
same for a single screen either with or without Xinerama support compiled
in.  And I guess just returning Nothing for the rest will also be
consistent? Why not export all of these in either case? Then developers
could code once, and their code would behave in the same way, regardless of
whether the Xinerama library isn't present or Xinerama itself isn't being
used, but we don't lose any of the exported power.  (Unless these functions
are really useless, in which case there's no need to bother...)
David Roundy

More information about the Xmonad mailing list