[xmonad] darcs patch: Config.hs: rm "Toggle the status bar gap... (and 3 more)

[gwern0 at gmail.com]

On 2008.01.08 09:00:12 -0500, Isaac Dupree <isaacdupree at charter.net> scribbled 5.6K characters:
> can we provide some easy way to add various/most parts of status-bar
> functionality when configuring, or is there a good reason it requires a
> "fair bit of configuration"?

I think this is worth pursuing. At the very least, *some* options and settings could be factored out. Why not be able to write a config.hs like 'main = xmonad $ dzen $ myConfig'? For that matter, I see no reason we couldn't allow for 'emulations' of other tiling window managers - 'main = xmonad $ ratpoison'...

It just needs someone to write it, is all.

...
>> As for dmenu: there's no more reason to think dmenu is installed
> > than, say, gmrun or XMC's ShellPrompt. This is still an external
> > dependency for what you seem to think is core functionality.
> > Replacing it with some call to ShellPrompt would actually be
> > better because it'd avoid runtime problems (User A hears about
> > XMonad, compiles and installs it, and wonders why she can't
> > launch programs - what's this 'dmenu' thing she sees on the
> > terminal prompt - assuming User A even looks there),
> > and it'd be eating our own dogfood.
>> I don't really see any palatable choices here. Either: we have
> > an external runtime dependency on something we can't assume the
> > user has installed; or, we use ShellPrompt/the Prompt framework
> > in general, and have a compile-time dependency on the
> > previously optional XMC; or, we include bare-bones prompt
> > functionality in the core.
>
> as long as mod-shift-return still means "make an xterm" per default, it is
> _possible_ to launch programs.  Funny that we can rely on xterm existing,
> but no such "prompt" program is an official part of X.  I wonder if xterm
> can be used somehow as a command prompt.

To continue to play Devil's advocate: I'm not sure we can rely on that. My system doesn't have xterm installed, for example, and I think other distributions besides Gentoo have unbundled xterm from X.org.

> Anyway, now that ~/.xmonad/xmonad.hs is a program, it can run anything it
> likes, including xmonad-contrib.  Perhaps we should make a default config
> that uses some things from xmonad-contrib (while still keeping xmonad-core
> usable), and somehow direct users to an install that includes contrib and
> that xmonad?  An xmonadcontrib package could install an "xmonad-contrib"
> binary that works like the "xmonad" one but with different defaults.  It
> seems the separation between "core" and "contrib" is useful for development
> even when some things in contrib are as stable as core? maybe?

Dunno. I'm not entirely sure how that works. I think it's ~/bin/xmonad which compiles ~/.xmonad/xmonad.hs and compiles in XMC if it's installed and ~/.xmonad/xmonad.hs needs it, so I'm not sure how XMC would compile its own xmonad.

--
gwern
bullion 8182 PRIME pink Iran Centro sardine CISD Wireless FLAME
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20080108/d94bb0d2/attachment.bin