On 2008.01.08 09:00:12 -0500, Isaac Dupree
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