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.
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.
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!)
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.
(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.)
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'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.
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.
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
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.
> 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.
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.
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.
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!
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.
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.
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.
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?
> "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'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.
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.
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.
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.
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.
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.
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.
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.
> 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.