Xmonad 0.10 was released | Hacker News Reader

Xmonad 0.10 was released

haskell.org

134 pointsvially69 comments

Installation: After you've gotten ghci and cabal from your favourite package manager, just do:

> sudo cabal install xmonad xmonad-contrib

Then you can get dmenu or dzen for a small menu and trayer for a small system tray.

Then use a premade config file from here: http://www.haskell.org/haskellwiki/Xmonad/Config_archive and mess around with it.

To learn the keybindings, print this out or make it your wallpaper: http://xmonad.wordpress.com/2009/01/19/xmonad-cheatsheet/

For them ubuntu users, if oneiric broke a lot of things you can follow this: http://markhansen.co.nz/xmonad-ubuntu-oneiric/ That should allow you to select an xmonad session as opposed to a unity one during login.

As a general rule you can simply use xmonad as your window manager and just launch gnome-settings-daemon (or was it gnome-config-daemon?) to get all the theming, font antialiasing, etc. If you run nm-applet manually, that should launch the networking stuff (if it didn't already). I haven't tried using xmonad with the ubuntu panel and stuff, so I don't know about that.

Edit: I use this one: https://github.com/vicfryzel/xmonad-config

It works great with multiple monitors, alt+w and alt+e move focus between monitors, and then I can swap which workspace is in which monitor really easily to move things around.

> I haven't tried using xmonad with the ubuntu panel and stuff, so I don't know about that.

Use XMonad.Config.Gnome.gnomeConfig as your base config. Log in with gnome as normal and do:

    pkill metacity
    pkill compiz
    sleep 3
    xmonad &

Not the most elegant solution, but it works.

That worked with Gnome 2, but I'm not sure how well that will work with Gnome 3 and/or Unity. Unity is pretty tied to Compiz (some portion of it is implemented as a Compiz plugin).

At this point, it's probably easier to either create your own session script to start up the parts of Gnome that you want along with XMonad (e.g. gnome-screensaver, gnome-power-manager, etc) or to see about using XMonad as the window manager for XFCE.

Also, you used to be able to set the $WINDOW_MANAGER environment variable in ~/.gnomerc, to turn on XMonad as the window manager.

> ...create your own session script to start up the parts of Gnome that you want along with XMonad...

On Ubuntu at least I've had success with http://markhansen.co.nz/xmonad-ubuntu-oneiric/

(Having the launcher floating around is annoying though, and removing it from the gnome-session file had some unpleasant side-effect that I don't remember.)

Can't you just select the session you want from gdm? Or did ubuntu take away that picker menu?

The default xmonad session just launches xmonad. Usually people want other things like pulse-audio, a power manager (like gnome-power-manager), etc launched.

This is why people want to use XMonad as Gnome's window manager.

I don't think using 'sudo' is necessarily a good idea: http://hackage.haskell.org/trac/hackage/ticket/611

The instructions from the wiki for Unity-2d integration also work fine: http://haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Unity_...

That runs xmonad with the unity panel; it doesn't add the launcher, but I was never a fan of that to begin with (in part because its interaction with xmonad wasn't great, but I never spent much time trying to get it working properly either so it might be possible). The key difference is the wiki assumes you're installing from cabal, where-as Mark's assume an apt-get installation which already comes with a .desktop file.

Note that the wiki instructions mention the need to explicitly add gaps at the top, which Mark's instructions didn't. (Also, that the wiki config doesn't actually launch the launcher!)

What is the correct way of starting exactly one instance of trayer if using gnome-session?

I'm also using XMonad on Arch Linux. I found it hard to setup correctly, but once it is, it's a real productivity booster. Firing up another terminal (Meta-Shift-Enter) and not worrying about it's position is a time saver.

If you want to try it out, I can help you by reducing the time needed to set it up. My dotfiles are here: https://github.com/wunki/wunki-dotfiles

Best nuggets for your setup can be found in xmonad.hs, xinitrc and Xdefaults files.

The underlying design invariant was that you should always be able to predict exactly what the screen would look like, before you perform an action. I'm glad that's the result we've achieved.

Is there an official announcement somewhere? The Xmonad blog seems dead, and the twitter account is not in a better state. It's a pitty because it gives the impression that the project is not actively developed.

There will be shortly. Sorry about the lack of noise online -- I switched jobs and cities, and haven't had time to do some of this kind of stuff. Adam Vogt has taken over as maintainer, and will be following up with an announce.

#xmonad on IRC is always populated with friendly and helpful xmonad cognoscenti

If you use Xmonad with GNOME 2/3 or Xfce, this panel applet/plugin can be handy: https://github.com/alexkay/xmonad-log-applet

(disclaimer: I'm the current maintainer)

I'm still sad that ion3 is getting so little love these days.

It's easily the most advanced of the tiling wm crop, and by a long shot. Just some bullets:

- Floating/tiled can co-exist on same workspace (just attach/detach as needed), can also trivially set filters to have e.g. all dialogs and "all gimp-windows" float automatically.

- The tabbed frames metaphor is infinitely superior to the "one window per frame" metaphor that everyone else is stuck with.

- All configuration and extension is lua. It's an absolute joy to work with.

- Mouse works as expected. Just drag frames to resize the grid, drag titlebars to move windows into other frames, etc.

Up to this day I don't understand how people put up with the obscure limitations of the other tiling wm's (foremost: the one window per frame constraint, forced set of layouts that never work quite right, etc. etc.)...

Most of the above list is actually supported by xmonad (and dwm, and awesome and ...). The two things that are really the defining characteristic of ion3 is that it is a user-defined layout (not a "dynamic" layout, a la xmonad), and that the clients are represented as a tree of windows, rather than e.g. a zipper or list of windows (which is how the nesting works).

xmonad and its cohort basically make the proposition that user-defined layouts are inefficient, and you can be more productive with predictable, automated tiling. They directly opposed ion3 in that regard.

Mouse, configuration, floating etc is all fairly standard everywhere.

xmonad and its cohort basically make the proposition that user-defined layouts are inefficient

Well, having worked with both I strongly disagree with that assumption.

Of course it's all a matter of preference but I believe there's a lot of "you don't know what you're missing when you never had it" going on. I've yet to observe an awesome|wmii|xmonad user who doesn't constantly get into fights with the WM because they can't just quickly resize or re-order a few frames in a truly predictable way.

I used ion2 for a few years. Now I've been using awesome for a few years. They're both nice. Overall, I think I prefer letting the wm arrange my windows. There are a few times where I have considered writing my own layouts, but that itch has never lasted long enough for me to scratch it.

It is too bad that ion is no longer maintained. Choice is good.

I thought one of the reasons that people didn't like ion3 was because the developer was really unpleasant.

No kidding: https://en.wikipedia.org/wiki/Ion_%28window_manager%29#Contr...

(In #xmonad, we have chortled a time or two about the self-destructiveness which has sent so many Ion users to Xmonad.)

Every single time I see news about window managers, I'm surprised that i3 (i3wm.org) isn't mentioned. i3 is the supreme tiling window manager. It's mature, fast, feature-ful and it's BSD-licensed. This looks like an advert, but I'm just a pleased user that's been on the i3 train since 2009.

The author's a tool and isn't interested in the community. Consequently, the community isn't interested in putting up with him.

My macbook died recently and I switched back to ubuntu for the week, first thing I did was install xmonad, its a really awesome environment to work within.

I do wish it played nicer with other window environment, some applications just dont work inside a modal interface and when they dont I just want my normal windows with title bar and buttons back

I havent installed it on my mac now its repaired, the fact I dont be able to use my normal mac apps kinda put me off, but I may give it another shot, if there was a way to have xmonad like behaviour with mac applications while preserving floating windows I would be in heaven (divvy etc most certainly do not count)

Its probably worth mentioning that despite following several tutorials, getting xmonad installed on 11.04 was a nightmare that left plain ubuntu pretty broken, I would like to see that process improved as well

  >  just want my normal windows with title bar and
  > buttons back

There are contrib packages that allow you to add small title bars to the windows. You could configure XMonad with a 'floating' workspace, and enable title bars on all of the windows in that workspace. Then just setup rules to automatically send all of the programs that have issues to that workspace.

I love how a "customizable tiling window manager" somehow requires the user to learn an unusual programming language and a dozen of inscrutable keyboard shortcuts.

It made my 24inch screen at the time far more manageable but it was supremely frustrating if I sometimes wanted a certain window to remain in a certain position without being disturbed.

> "customizable tiling window manager" somehow requires the user to learn an unusual programming language and a dozen of inscrutable keyboard shortcuts

Languages are our best tool for expressivity.

And a well-designed language is better than an ad hoc configuration language any day of the week (see e.g. vimscript for how not to do configuration).

By choosing to use a full language for configuration, we have made possible an enormous ecosystem of user-contributed components -- because the configuration language was rich enough to support them.

Horseshit! That's what APIs are for :P.

You could have accomplished all of this just fine but left the config in yaml and I would have personally been a happier person for it.

YAML configuration is possible, if you want. Just load the YAML file in your xmonad.hs config, and translate it (using the regular config language) into the Config data type xmonad actually uses.

You could implement all sorts of funky config formats, by translating them down to the underlying (richer) format. Go nuts!

I know it's possible, but goddamnit I didn't want to learn Haskell in the first place! That is my bone of contention.

Yes, yes, it might make me a better person but I want to try XMonad more than I want to fuck around with Haskell.

Personally I believe that optimizing for the technical user is much more important than user-friendliness in developer tools, especially window managers and text editors. Most people don't have the desire or the motivation to write full-featured developer tool extensions, but those who do should have the full power of a language like Haskell at their fingertips.

I think the fact that no one has bothered to write a limited configuration format is telling. It seems to indicate that people who have learned Haskell don't see any benefit in it and appreciate the flexibility offered to them.

  > I think the fact that no one has bothered to write a
  > limited configuration format is telling.

Specious reasoning. There are a lot of people that just know enough Haskell to fiddle with their XMonad config and/or copy-paste bits from other people's XMonad configs.

I'd say the ratio of XMonad users who would build a easy-config system to total XMonad users is small. You're trying to claim that total XMonad users = X, and since X people are using it without creating the 'new system,' it means that no one sees the utility in it.

No, I'm saying that of all the XMonad users who know Haskell, none has bothered to write an alternative configuration system. That is, once you know Haskell you seem to no longer find interest in such a system.

Try awesome[1]. It uses Lua, which is probably a more familiar language(I never learned Lua, but am still able to make minor changes to the config file, something I wouldn't try with Haskell). That, combined with a few other things, is what made me move from xmonad to awesome.

[1] http://awesome.naquadah.org

If it's just the choice of language that's the issue, try wmii. The default config is written in Bourne shell, but all of the actual interaction between the config and the wm is done through a plan9-style api, so you can configure it in any language you want. The Ubuntu package comes with sample configs written in Python and Ruby in addition to Bourne shell.

A yaml config would still be weak (this has been discussed before: http://www.haskell.org/pipermail/xmonad/2009-February/007239... )

But the nice thing about starting with a full language using the normal API is that you can always water it down to get something less powerful and easier to use, and this has been done with Xmonad before, as 'xmonad-light'. See https://braincrater.wordpress.com/2008/08/28/announcing-xmon... http://www.haskell.org/pipermail/xmonad/2008-August/006211.h...

xmonad-light has no users and may be bitrotten by now, which shows how much it appealed to Xmonad users.

XMonad users by definition already know at least a minimal amount of how to create their XMonad config file. That's like saying: "We created a Linux distro for the masses and it didn't appeal to power users, therefore nobody wants it."

You're also dismissing the possibility that is just sucked, and was not an improvement in configuration interface.

I think the parent is asking why it's not possible to have a plugin system + a simple config file (or GUI config app).

There are a lot of common things that people do with XMonad, so I'm sure that a number of them could be consolidated into plugins with simple config options.

You can always write a configuration extension that takes $your_favorite_text_format into the data structure that configures xmonad.

In fact, there is a text-based configuration system (implemented on top of the full-language configuration system) that does as you describe in the contrib repo somewhere. You could also easily do e.g. JSON, or YAML or whatever.

And that's possible because we use a full language as the base layer. So "dumber" config systems can be layered on top without changing anything.

I'm not arguing against the full language base layer. I'm saying that the op is complaining that he/she needs to learn Haskell to create an XMonad config.

Even if I want to use one of those libraries, I still need to create an xmonad.hs file, and import the library. Vs having an xmonad binary that determines libraries/etc from a config file, and all code-level customizations are libraries/modules.

   love how a "customizable tiling window manager" somehow
   requires the user to learn an unusual programming language
   and a dozen of inscrutable keyboard shortcuts.

It doesn't require that, but up until now the only people that cared about "customizable tiling window managers" were people that wanted to do so. Most of these window managers are created by programmers/terminal junkies that would prefer that most things be a text interface. Just look at ratpoison and stumpwm. They're made to have an Emacs-like interface to the window manager. How accessible is an Emacs interface to a non-technical user?

Dude, what non technical users? We're talking about Linux window managers.

I'm a technical user. I program for a living. I don't care to learn Haskell in order to use a window manager :P. This is all I'm saying.

Eh, you should learn Haskell even if you're not going to be using the window manager ;)

> "customizable tiling window manager" somehow requires the user to learn an unusual programming language and a dozen of inscrutable keyboard shortcuts

You might be interested in the tiling window manager I wrote with Node.js (mixu/nwm on github). It's very much inspired by xmonad and dwm, but the engine is Javascript running in Node.js with a native extension for X11 operations/events.

All layouting decisions are made in JS - in fact, the C++ binding doesn't even know the position of the windows or the dimension of the monitors; it's all tracked in JS. It should be easier to customize, though definitely not as battle-tested as xmonad.

How does it differ from existing tiling window managers, except the JavaScript spin? It sounds interesting, but it always makes me think twice if the only motivation for a new project is to do the same in a different language.

I just installed xmonad on 11.10 last week. It was very straightforward---didn't even need a tutorial. It's just "sudo apt-get install xmonad". The hard part was trying to customize xmonad without knowing Haskell.

xmonad is uber-wonderful but a good beginner documentation would be really awesome.

I would like to have, on the official site, a list of distro, and for each, a tutorial that have been tested and works. Instead, one needs to hunt for blog post that are either incomplete or not applicable.

The latest Ubuntu upgrade was really a nightmare in this respect. had to mix xfce + xmonad but my setup is far from optimal...

>> xmonad is uber-wonderful but a good beginner documentation would be really awesome.

Why don't you write one? A lot of the xmonad (and other tiling wm) communities are battle scarred veterans who have been using dwm (the ancestor of xmonad, awesome et al) since day one and they don't need no stinking documentation :) And besides, one of the core ideas of dwm and (some of) it's successors is that the source code is the documentation.

So if you're a newb and would belong to the target group of the docs you're requesting, you're the perfect individual to write them.

I'm sure all the old timers on the IRC channel will be glad to help you to get started and will be even more delighted if you finish a doc.

Another one of the core ideas of dwm is "no noobs" which might explain the lack of documentation.

If true (and I'm not sure it is), that's a shame, because it essentially means new adoption is discouraged, and that's death to a project.

Our project focuses on advanced and experienced computer users. In contrast with the usual proprietary software world or many mainstream open source projects that focus more on average and non-technical end users, we think that experienced users are mostly ignored. - from Suck Less Philosophy at http://suckless.org/manifest/.

I don't feel this translates to "no noobs" as much as it means "don't stop with the noobs." I'm pretty sure inexperienced users are welcome, but there's no interest in adding hand-holding features that conflict with the philosophy of "keeping things simple, minimal and usable." I use dwm & dmenu all the time, and have developed a real appreciation for the Suck Less approach (but I'm not a newbie, so I guess I'm safely in their target audience).

dwm in particular mentions that it's elitist in order to prevent stupid questions from novices:

Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

Also anyone who has ever subscribed to the suckless mailing list can testify to the elitist sentiment among many of its users.

Anti-noob is perhaps a bit harsh, but dwm is definitely elitist. It is designed to keep its user base small (see my reply to qjz).

xmonad is well documented:

* http://xmonad.org/documentation.html

E.g.

* http://xmonad.org/tour.html * http://haskell.org/haskellwiki/Image:Xmbindings.png

It was always intended to be the antithesis of dwm in terms of friendliness and accessibility.

I have heard good things in the past about beginners using Goerzen's tutorial: http://www.haskell.org/haskellwiki/Xmonad/Config_archive/Joh...

Scrotwm is a small dynamic tiling window manager for X11. It tries to stay out of the way so that valuable screen real estate can be used for much more important stuff. It has sane defaults and does not require one to learn a language to do any configuration. It was written by hackers for hackers and it strives to be small, compact and fast.

It was largely inspired by xmonad and dwm. Both are fine products but suffer from things like: crazy-unportable-language-syndrome, silly defaults, asymmetrical window layout, "how hard can it be?" and good old NIH. Nevertheless dwm was a phenomenal resource and many good ideas and code was borrowed from it. On the other hand xmonad has great defaults, key bindings and xinerama support but is crippled by not being written in C.

Is there a compelling reason for somebody already using Awesome WM to look into Xmonad? Seems like I'm hearing about it more often these days.

I am an Xmonad user that tried Awesome, and the main thing that didn't work for me is that it seemed that Awesome workspaces (tags) were tied to particular monitors. Perhaps I just didn't take the time to figure out how to do it properly, but that was a deal-breaker for me.

In Xmonad, I have configured twenty different workspaces, and I can easily swap them in and out of any given monitor. With a triple-monitor configuration, this is quite handy.

That's what did it for me too. I'm sure there is a way in awesome to do it but its not as easy as xmonad.

Xmonad seems to not get in the way as much as awesome. For my purposes xmonad is just a lot simpler, but I am sure I am barely scratching the surface feature wise.

A lot of the awesome docs/screenshots reminded me of enlightenment-porn back when e17 seemed like vaporware. I don't need crazy graphs/apps/eye-candy just help me arrange organize my windows and go away.

The crazy stuff doesn't come with a base awesome install, that's stuff people added on their own. The base install looks like this: http://en.wikipedia.org/wiki/File:Awesome_screenshot.png

XMonad _is_ simpler, since awesome comes with a taskbar, system tray, and clock by default.

Maybe Awesome is more stable now, but one of the reasons that I (and people I know) gave up on Awesome was how often the configuration interface changed, even once they switched it to Lua, the API would change between point releases.

If I upgrade from XMonad 0.9 => 0.10, I don't have to completely redo my config file, because a good portion of the API has changed.

been using xmonad for a couple of years. config is so minimal that it makes it vey simple to replicate the exact same environment on all my machines (laptops and desktops), with no ties to the underlying linux distribution.

Anybody have a link to some good screenshots of Xmonad 0.10?

http://www.haskell.org/haskellwiki/Xmonad/Screenshots

I wish I could replace my osx window manager by xmonad =_)

I'll go tell my coworker. He's the one industry programmer who gives a shit about Haskell.

Looks like someone missed the reference:

http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

Providing a reference for your joke doesn't really change much. I don't think you were downvoted because anyone thought your comment need citations, or because they weren't sure if it was actually supposed to be a joke.

Perhaps it was just a bit trite, and/or irrelevant.

So would you say that the same goes for Steve's article --which makes exactly the same point?

Reply on news.ycombinator.com