On the other hand, xmonad has a remarkably well defined set of defaults so I for one am able to be very productive with them very well. My personal config provides stuff that I use maybe 3 % of the time.
That's extremely bloated. ;) For several years early on in its life, the entire XMonad core codebase was just under 500 lines of code. Of course, I believe the Zipper rewrite (many moons ago) was what increased the size somewhat, and it was for the best... It's even small enough someone did a formalized Coq proof of the core data structures (i.e. they proved that XMonad cannot 'crash' in several ways.) :)
I have used it very fondly almost for a decade now (since 0.0!) and it is a good piece of software. I don't think I've changed my config more than 10 lines in like 7 years...
If anyone wants to see the old school cool: check out XMonad 0.3. This was a good release, trust me:
$ git clone https://github.com/xmonad/xmonad.git && cd xmonad
$ git checkout -b old v0.3
$ cloc Config.hs* Main.hs Operations.hs StackSet.hs
5 text files.
5 unique files.
1 file ignored.
http://cloc.sourceforge.net v 1.60 T=0.01 s (561.3 files/s, 213300.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Haskell 4 211 625 684
-------------------------------------------------------------------------------
SUM: 4 211 625 684
-------------------------------------------------------------------------------
I also take back what I said earlier. I have been using XMonad for almost exactly a decade, since 0.1 was released in April 2007, and I used the pre-release. So its 10th birthday is very close.
I also think it's interesting to note that XMonad is a pretty good example of stable software that doesn't need to change much. Lots of tiling WMs probably fall in this category by some metric, I'd say. For example, the v0.3 version of XMonad had exactly 572 commits in its history at that point:
The HEAD version of XMonad, 0.13, only has exactly 1,265 commits, at the time of this writing. But it has been released almost 10 years later. So that's only a little over 2x as many commits over the course of a decade, and roughly 3x more code at the core level. It does exactly what it needs to do -- so it hasn't needed to evolve much more than that. Files like StackSet (the most central data structure in XMonad) have almost not changed in 10 years, modulo some shuffling, comments, re-exports. That's quite nice, really.
(Where all the extra code came from between 0.3 and 0.13 is left as an archaeology exercise to the reader.)
xmonad source itself can be small but, running xmonad consumes a lot of memory due to huge ram/space requirements of the ghc (haskell) (edit I don't remember exactly what consumed so much memory). that's why i moved to i3 wm after years of xmonad use.
I moved to i3 just for configuration ease. That you would move to save the difference in a tiled window manager might be a little over valuing the memory saved :)
At least it isn't I left KDE bloat to go to Gnome when Gnome was actually having a larger foot print back in the day.
Same, but moved from Awesome WM to i3. Config is simple but powerful, and i3 itself brings so much to the table out of the box that your customization footprint is going to be smaller than that of scriptable WMs.
I tend to use xfce these days, but when I'm really getting sshdirty, I'm usually in i3, but I tried and still want to use awesome mostly because I try hard to favor GPL products, but i3 is just so easy and works without nearly as much work.
"Curious, why do you favor GPL over BSD as a user?"
Because BSD licenses are abused by the tivoization of devices far too often, and I think GPL(v3) is one of the few licenses that gets in the way of that. (because to be fair, GPL1/2 were also abused in this way, but I think GPLv3 has fixed most of those loopholes)
BSD style licenses are about freedom for the developer, not the user, whereas GPL style licenses are about freedom for the user. All devs are also users, but not all users are devs, therefor GPL licenses are for freedom for a greater number of people as well. (Can you tell I think RMS is/was right?)
Also, you can theoritcally license BSD stuff under GPL if you fork it and make the new code contribs GPL, but enforcing it would be almost impossible, so I don't think that's a valid get out of license free card.
I tried many of the tiling WMs, and XMonad was the one I liked second best behind i3. One thing I really liked about XMonad was the "flip this window with the "main" window. But marks and "stack" or "full screen" in i3 work for me. The thing about XMonad was that I don't know Haskell and so the config was something I would cut and paste snippets into and pray that they'd work.
Yeah, that comment doesn't make much sense as it stands. GHC is a compiler not a runtime. Functional languages like GHC-compiled Haskell are not known for extreme memory efficiency in all cases, but it depends entirely on the program. Unless I'm not aware of how XMonad actually runs.
And you have to recompile it if you change your xmonad.hs config file. There's no interpretation going on at runtime - well except when you actually run xmonad with an interpreter like ghci.
I'm currently showing ~8.5M resident and ~4.6M shared. You can certainly do "better" than that with a different tiling window manager, but before going nuts trying to improve that or condemn XMonad/GHC, I'd definitely suggest running "top" and pushing "M" (capital matters) and seeing where it shows up in your listing. snapd and NetworkManager is taking more RAM for me right now than XMonad by a bit, and emacs, konsole, pidgin, thunderbird, clementine, and firefox all grossly outweigh it. Optimizing your window manager to take 1MB instead of 4MB of RAM is a complete and utter waste of time if you're running any web browser at all, that's less than a single big image's worth of RAM.
But the configuration is also compiled into the binary. And if you really need runtime configuration without the weight of GHC, well, Haskell is well known as an excellent language to write interpreters in... (I think someone already did that for Xmonad, actually.)
I switched to i3 a couple of years ago, after using XMonad for about two years. Hopefully things have improved since then, but I kept falling into Cabal hell every time I tried to make a configuration change and I got fed up. At the time I concluded that XMonad was for people who use Haskell regularly and know how to navigate its package system.
My favorite part of XMonad is XMonad.Actions.Navigation2D[0], which allows you you use direction navigation via keybinding to switch between windows. A proof that the technique for this allows you to visit any window, no matter how they are arranged is given in this paper[1].
fvwm2 has this and I miss it dearly since I switched to i3 a while back. It was fantastic. I would arrange my screens in a 3x3 grid and put my most commonly used one in the center. That gave me four other screens that were only one keystroke combo away.
It's just not the same in i3. I can do meta+screen# but it's nowhere near as easy.
While only working in 1D (up/down for workspaceswitch; left/right for monitor switch), I use a similar "geometric navigation" from within i3 in place of the Meta+Number default shortcuts.
I've been thinking of trying XMonad for a while, and looks like this is the opportune time. Anyone know if there's an easy "switch to last used window" functionality?
"Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.
Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc."
Sway is a drop-in replacement for the i3 window manager, but for Wayland instead of X11. It works with your existing i3 configuration and supports most of i3's features, and a few extras.
Sway is a great project. I use it on a laptop with Intel graphics. I've tried to use it elsewhere, but I've found that the limiting factor is everything else -- applications that are still using X11 (supported under Wayland but often with surprising behavior), drivers that don't support Wayland, or don't support it properly, and the general immaturity of the Wayland world. Wayland is the graphics equivalent of PulseAudio circa 2009: clearly the way of the future, on an upward trajectory, but still experiencing growing pains and making a lot of people angry.
Yes, back when I used Xmonad I also used the mouse a lot. You can use Super+Left mouse button to move windows around and Super+Right mouse button to resize windows.
I don't think there's a tiling wm that puts mouse first. I think years ago there was some work on KDE to add some tiling behaviour, but I don't know if it was merged and buried in settings somewhere, or it was a plugin, or a patch. I only remember some demonstration video from years ago.
I'm pretty sure there's also Openbox setup with tiling behavior.
I use dwm with some patches, and some customizations that allow for more mouse use.
For instance mouse wheel on the tagbar cycles through tags, mouse wheel on window title cycles through windows, middle click on window title makes currently selected window master, control + mouse wheel on the window title pushes selected window around, mouse wheel on status text increases or decreases sound volume, middle click on status text kills selected window, ctrl + mouse-wheel-up sends selected window to that particular tag, etc etc etc...
So yeah, it's doable in dwm. It's not "mouse first" but most used actions are also doable with mouse, in addition to the keyboard.
It's not too hard, spend an afternoon, or two and you can get it working that way.
It's a hybrid WM with first class support for normal floating windows (the default) and first class support for tiling. However, it's also designed for multiple monitors and therefore breaks a couple chosen EWMH standards, so your favorite pagers may not work in a multiple monitor setup.
Speaking as a user of XMonad for a few years now, I think the way tiled window managers tend to present more as toolkits for assembling your own tiled window manager rather than one that's just ready-to-go for everyone is as much a disadvantage as it is an advantage. (Yes, they all have default configurations of course, but you are generally expected to customize.) When people occasionally ask me about it, I tend to advise people to pick their tiled window manager less on the putative features and more by what programming language that it is implemented in that they are comfortable in. Now, if you're fluent in one of the languages in question, that's awesome, but it does raise the bar for a lot of people.
You don't have to be an "expert" in Haskell to use XMonad, but it sure doesn't hurt if you want to do some heavier-duty customizations, like use modules that aren't even nominally a part of XMonad.
You seem to know XMonad well, so I'll ask a question. Does it support manual tiling and application tabs yet? I couldn't use it because it felt too basic to me last time I checked it.
I'm pretty sure the core XMonad doesn't, but the core XMonad doesn't do a lot of things, really. If you Google "xmonad tabs", I get http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-T... I have no idea if it will do what you want because I've never used it. That's in xmonad-contrib.
I don't know what you mean by "manual tiling", so I can't say if it's supported. I know I do some manual things but most of my manual things are out of the tiling context entirely.
By manual tiling I mean not having a reduced hardcoded number of layouts, but being able to split every "container" horizontally and vertically, moving and resizing windows freely (ideally using mouse like ion3 did).
While i3 does not (AFAIK) support mouse resizing, it does everything else you've mentioned out of the box: split containers horizontally/vertically; supports stacked and tabbed layouts; and with a few config lines, resize both floatable and fixed (i.e. part of stack/tab group) containers.
Yes, I know, I tried it, it has some ideas that ion3 had before, but I still find it lot less flexible than ion3. Though in this case I was asking specifically about XMonad.
Fair enough, ion3 sounds quite interesting, unfortunate that development stopped.
As for XMonad, like Awesome WM, you can probably customize things however you see fit. Just need to know Haskell/Lua and the WM well enough to do so, which may be less than obvious for most.
With i3 you don't need a language. The configuration is a simple text file. That is why i3 has been my Tiled Window Manger for 4 years now.
> Configuring i3
This is where the real fun begins ;-). Most things are very dependent on your ideal working environment so we can’t make reasonable defaults for them.
While not using a programming language for the configuration, i3 stays quite flexible in regards to the things you usually want your window manager to do.
A text file, yes, "simple", well, no, I wouldn't say so. It's not i3's fault; I'd say that comes pretty close to exposing the essential complexity without much accidental complexity. (Translating back out of architecture-astronaut-speak, that's pretty high praise.) But there's a lot of essential complexity. If I plot the complexity of a non-Haskell expert's .xmonad file, an i3 file, and just using stock Ubuntu Gnome, .xmonad and i3 end up pretty much next to each other from the perspective of the Gnome user.
That is a Strawman Argument. What person wants a tiled window manager and not customize it? They want a keyboard driven ui without the ability to change the defaults (Which are some of the best defaults ever)
It is like saying Notepad is simple and Visual Studio Code is complex because it has a plain text json file for customization. They are different tools. For the tool visual studio is much easier then say VIM.
So is i3 MUCH easier to configure then XMond and Awesome.
Wow this rabbit hole is impressive. I'll summarize to the best of my understanding (I'm no expert in X).
Basically, chrome uses an X property called _NET_WORKAREA (which is basically supposed to be a rectangle that includes all the parts of the screen that aren't the toolbars) to clip popup menus for dropdowns, so they don't draw over your taskbar or whatever.[1]
Earlier this year, they fixed a race condition so that now they listen for updates to _NET_WORKAREA changes[2], which fixed an issue where the clip area would be wrong for users who hot (un/)plugged extra monitors on relatively "standard" distros like Linux Mint. Basically, you could only see the drop downs on your primary monitor, because _NET_WORKAREA was out of date.
Once this change finally landed in stable, XMonad users noticed that now they couldn't see dropdowns on ANY monitor if they were changing workspaces and had multiple monitors. It turns out that this is because Chrome reads _NET_WORKAREA from the root window, and XMonad (unlike mainstream WMs) uses separate root windows per monitor. Now that Chrome was watching for changes, Xmonad and chrome were miscommunicating with each other about the current clip area. Chrome works around-ish this by only doing the clipping on the primary display[3] "Since that is where the 'desktop chrome' usually lives, this works ok in practice."
The workaround on the XMonad side is to just stop setting _NET_WORKAREA altogether[4], which is the same thing that i3, awesome and qtile do. Note that they had originally set this property in the first place because not having it caused Gtk and Qt malfunctions. To further complicate things, some Display Managers like LightDM set _NET_WORKAREA itself, so XMonad has to actively delete this property when it starts instead of ignoring it altogether.
I used XMonad for many, many years. During these years it served me well and I really loved it. However I switched to AwesomeWM about 2 years ago and couldn't be happier. I was able to easily make Awesome behave just like xmonad for parts I cared about, so the transition was pretty painless.
Top 3 reasons I switched:
1. Multi monitor support is far better with awesome and it worked perfectly out of the box with my 3 displays.
2. Programs that were a bit glitchy under xmonad had no such glitches under awesome.
3. LUA configuration files make it far easier for me to customize behavior and extended it. With Xmonad's Haskell I always felt like a noob.
In what way is multi monitor support better? In my opinion nothing comes close, I've not used anything else which considers each display an independent workspace and let's you move those workspaces between displays.
For certain Java apps you have to set an environment variable to tell them that your window manager has a different name for them to run properly. Mostly things based off of old versions of Eclipse.
I used to run AwesomeWM and liked it a lot. But I decided I wanted to go back to running a desktop environment and run a tiling WM within one. There are things I miss but I actually like XMonad's approach to multiple displays better.
XMonad hits a sweet spot no other window manager does for me:
import XMonad.Config.Mate
main = xmonad mateConfig
and just like that I have XMonad running inside my mate desktop, without the need to manually configure a status bar for volume, wifi, keyboard input language, clock, etc.
I don't even use tiling that much as I prefer to have one app per workspace, but just having focus-follows-mouse and the option to tile if I need it is really sweet.
I do the same thing with Gnome. There's an Ubuntu PPA at ppa:gekkio/xmonad that takes care of creating a desktop session for me and then it's just a matter of adding the same thing with s/mate/gnome/ and then away I go.
I'm glad to see a new release of XMonad! Two questions:
1. Is there any way to use XMonad but keep the standard Ubuntu menu bar for access to desktop menus? This used to be possible with older Gnome desktops, but it had gotten increasingly harder in recent years.
2. Does XMonad work well on Retina/HiDPI displays? A year or two ago, it still had lots of rough edges.
1) I don't think it's possible to keep the standard Ubuntu menu but you can use XMonad in other desktop environments like Mate or Gnome. You'll have to do a bit of configuration but it's not bad, see my other comment.
2) I run XMonad in gnome and it mostly works without problem. The only thing I had to change was set my browser launching keybinding to run
Windows 7 has really basic tiling -- super-left and super-right will put windows in a vertical split arrangement. Windows 10 adds another split so you can have four quadrants. Nowhere near i3, but the Windows user experience is forever lagging Linux.
If you want purely manual tiling, with windows being arranged normally until you tile them, there is WinSplit Revolution (can't find the canonical link right now). It basically does the same thing the tiling keyboard shortcuts in Windows 7+ do, but with more options and granularity.
If you want automatic, dwm-style tiling, there is a project called [bug.n][1]. I am currently using it, mainly because besides offering tiling windows, it is also the least-bad way to get multiple workspaces on Windows that I could find.
And are disappointed when using my Ubuntu desktop of the lack of simple tiling inside Unity. In my ancient fvwm and kde days there were more options.
I don't want to change my whole windows manager to Xmonad or i3, as I try to keep my setups fairly vanilla (as I use a lot of different machines/VMs and need a quick setup), but adding an unintrusive simple tiling option would be nice.
I have tried X Tile which is ok, but crashes too often and also moves full screened windows from my 2nd monitor onto my main monitor which is annoying.
An additional joke, likely unintentional (but who knows), is that the original Monads of Leibniz, were viewed as completely independent, 'windowless', objects that only seemed to interact with one another via God's elaborate choreography, which he termed the 'pre-established harmony' of the universe.
XMonad is moving really fast. It was on 0.11 for quiet sometime and now it it 0.13.
Love/Miss XMonad, since I use mac work. One of the reason s I want to get a Linux machine for personal use.
117 comments
[ 6.9 ms ] story [ 231 ms ] threadContrib and extras, where a lot of the useful stuff is defined are here:
https://github.com/xmonad/xmonad-contrib
https://github.com/xmonad/xmonad-extras
I have used it very fondly almost for a decade now (since 0.0!) and it is a good piece of software. I don't think I've changed my config more than 10 lines in like 7 years...
I also think it's interesting to note that XMonad is a pretty good example of stable software that doesn't need to change much. Lots of tiling WMs probably fall in this category by some metric, I'd say. For example, the v0.3 version of XMonad had exactly 572 commits in its history at that point:
https://github.com/xmonad/xmonad/commit/dede0a2ce91eebdb1c02...
The HEAD version of XMonad, 0.13, only has exactly 1,265 commits, at the time of this writing. But it has been released almost 10 years later. So that's only a little over 2x as many commits over the course of a decade, and roughly 3x more code at the core level. It does exactly what it needs to do -- so it hasn't needed to evolve much more than that. Files like StackSet (the most central data structure in XMonad) have almost not changed in 10 years, modulo some shuffling, comments, re-exports. That's quite nice, really.
(Where all the extra code came from between 0.3 and 0.13 is left as an archaeology exercise to the reader.)
At least it isn't I left KDE bloat to go to Gnome when Gnome was actually having a larger foot print back in the day.
The closed source forks for the BSD licensed projects... sure, don't use those but the projects themselves are good to go.
In my case, because I know that any contributions I make will become part of the software commons and won't be taken proprietary.
Because BSD licenses are abused by the tivoization of devices far too often, and I think GPL(v3) is one of the few licenses that gets in the way of that. (because to be fair, GPL1/2 were also abused in this way, but I think GPLv3 has fixed most of those loopholes)
BSD style licenses are about freedom for the developer, not the user, whereas GPL style licenses are about freedom for the user. All devs are also users, but not all users are devs, therefor GPL licenses are for freedom for a greater number of people as well. (Can you tell I think RMS is/was right?)
Also, you can theoritcally license BSD stuff under GPL if you fork it and make the new code contribs GPL, but enforcing it would be almost impossible, so I don't think that's a valid get out of license free card.
It'd be about the same as GPL enforcement as is. I don't see any reason this would introduce a special circumstance.
[0] https://github.com/xmonad/xmonad/blob/master/src/XMonad/Core...
https://lists.gnu.org/archive/html/guix-devel/2017-02/msg009...
Documentation is extraordinary and really easy to follow once I understood how to read it, years ago.
The only sore spot is monstrous GHC size, that compiler needs to get much smaller to be really good from all angles.
I'm a big fan of bspwm, though, and kwm at work on macOS.
[0]- http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-...
[1]- https://web.cs.dal.ca/~nzeh/xmonad/Navigation2D.pdf
It's just not the same in i3. I can do meta+screen# but it's nowhere near as easy.
Here is how I solved this for me: https://fmos.at/2016/06/30/my-i3-dual-screen-workflow/
[1]: https://github.com/xmonad/xmonad/issues/38
I for one am willing to contribute the day wayland becomes too mainstream.
"Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.
Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc."
i3 has sway http://swaywm.org/
Sway is a drop-in replacement for the i3 window manager, but for Wayland instead of X11. It works with your existing i3 configuration and supports most of i3's features, and a few extras.
Last I checked Sway hasn't yet reached feature parity with i3 (though need to see if the missing bits are things are currently rely on in i3).
People that still complain about pulseaudio drives me nuts. Sound was the second worst thing about Linux, only wirelesss internet was worse.
I tried i3 and found the basic concept nice, but it required keyboard shortcuts en masse.
https://arch-ed.dk/xmobar-clickable-workspaces
I have a friend who used Awesome on a tablet, so it's clearly feasible.
I'm pretty sure there's also Openbox setup with tiling behavior.
I use dwm with some patches, and some customizations that allow for more mouse use.
For instance mouse wheel on the tagbar cycles through tags, mouse wheel on window title cycles through windows, middle click on window title makes currently selected window master, control + mouse wheel on the window title pushes selected window around, mouse wheel on status text increases or decreases sound volume, middle click on status text kills selected window, ctrl + mouse-wheel-up sends selected window to that particular tag, etc etc etc...
So yeah, it's doable in dwm. It's not "mouse first" but most used actions are also doable with mouse, in addition to the keyboard.
It's not too hard, spend an afternoon, or two and you can get it working that way.
Oberon OS did it.
It's a hybrid WM with first class support for normal floating windows (the default) and first class support for tiling. However, it's also designed for multiple monitors and therefore breaks a couple chosen EWMH standards, so your favorite pagers may not work in a multiple monitor setup.
https://i3wm.org/docs/userguide.html#keybindings
I find it funny that so many little paper cuts that can be fixed in less then 30 minutes makes people move in tiled window managers.
i3 greatest strength is its ease of configuration compared to most other twm.
Some visual alternative, like the Windows 8 start menu, to choose apps would be nice on a mouse button.
I like the command menu, when I'm programming, but often I just want to click some icons and be done with it.
https://www.slant.co/topics/3945/~linux-app-launchers
You don't have to be an "expert" in Haskell to use XMonad, but it sure doesn't hurt if you want to do some heavier-duty customizations, like use modules that aren't even nominally a part of XMonad.
I don't know what you mean by "manual tiling", so I can't say if it's supported. I know I do some manual things but most of my manual things are out of the tiling context entirely.
https://hackage.haskell.org/package/xmonad-contrib-0.13/docs...
As for XMonad, like Awesome WM, you can probably customize things however you see fit. Just need to know Haskell/Lua and the WM well enough to do so, which may be less than obvious for most.
It's not heavily developed, but plenty stable. (actually I have a WIP PR open adding icon support)
> Configuring i3
This is where the real fun begins ;-). Most things are very dependent on your ideal working environment so we can’t make reasonable defaults for them.
While not using a programming language for the configuration, i3 stays quite flexible in regards to the things you usually want your window manager to do.
http://i3wm.org/docs/userguide.html#configuring
It is like saying Notepad is simple and Visual Studio Code is complex because it has a plain text json file for customization. They are different tools. For the tool visual studio is much easier then say VIM.
So is i3 MUCH easier to configure then XMond and Awesome.
The initial version of Oberon OS and the System 3 successor, but they are dead now.
Long live the best WM ever!
[1] https://github.com/xmonad/xmonad/issues/42
Basically, chrome uses an X property called _NET_WORKAREA (which is basically supposed to be a rectangle that includes all the parts of the screen that aren't the toolbars) to clip popup menus for dropdowns, so they don't draw over your taskbar or whatever.[1]
Earlier this year, they fixed a race condition so that now they listen for updates to _NET_WORKAREA changes[2], which fixed an issue where the clip area would be wrong for users who hot (un/)plugged extra monitors on relatively "standard" distros like Linux Mint. Basically, you could only see the drop downs on your primary monitor, because _NET_WORKAREA was out of date.
Once this change finally landed in stable, XMonad users noticed that now they couldn't see dropdowns on ANY monitor if they were changing workspaces and had multiple monitors. It turns out that this is because Chrome reads _NET_WORKAREA from the root window, and XMonad (unlike mainstream WMs) uses separate root windows per monitor. Now that Chrome was watching for changes, Xmonad and chrome were miscommunicating with each other about the current clip area. Chrome works around-ish this by only doing the clipping on the primary display[3] "Since that is where the 'desktop chrome' usually lives, this works ok in practice."
The workaround on the XMonad side is to just stop setting _NET_WORKAREA altogether[4], which is the same thing that i3, awesome and qtile do. Note that they had originally set this property in the first place because not having it caused Gtk and Qt malfunctions. To further complicate things, some Display Managers like LightDM set _NET_WORKAREA itself, so XMonad has to actively delete this property when it starts instead of ignoring it altogether.
Anyway, it was a pretty interesting read.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=510079 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=510079... [3] https://bugs.chromium.org/p/chromium/issues/detail?id=510079... [4] https://github.com/xmonad/xmonad-contrib/pull/79#issuecommen...
But if I remember correctly, those are the exacts features why I liked awesomewm, independent workspaces that you can move between displays.
What sorts of programs, what kinds of glitches?
I don't even use tiling that much as I prefer to have one app per workspace, but just having focus-follows-mouse and the option to tile if I need it is really sweet.
1. Is there any way to use XMonad but keep the standard Ubuntu menu bar for access to desktop menus? This used to be possible with older Gnome desktops, but it had gotten increasingly harder in recent years.
2. Does XMonad work well on Retina/HiDPI displays? A year or two ago, it still had lots of rough edges.
Unity 3D is a Compiz plugin so you can't use XMonad with it.
Gnome 3.8 and later only support gnome-shell as a window manager; it is not possible to integrate xmonad or any other window manager with it
2) I run XMonad in gnome and it mostly works without problem. The only thing I had to change was set my browser launching keybinding to run
If you want purely manual tiling, with windows being arranged normally until you tile them, there is WinSplit Revolution (can't find the canonical link right now). It basically does the same thing the tiling keyboard shortcuts in Windows 7+ do, but with more options and granularity.
If you want automatic, dwm-style tiling, there is a project called [bug.n][1]. I am currently using it, mainly because besides offering tiling windows, it is also the least-bad way to get multiple workspaces on Windows that I could find.
[1]: https://github.com/fuhsjr00/bug.n
And are disappointed when using my Ubuntu desktop of the lack of simple tiling inside Unity. In my ancient fvwm and kde days there were more options.
I don't want to change my whole windows manager to Xmonad or i3, as I try to keep my setups fairly vanilla (as I use a lot of different machines/VMs and need a quick setup), but adding an unintrusive simple tiling option would be nice.
I have tried X Tile which is ok, but crashes too often and also moves full screened windows from my 2nd monitor onto my main monitor which is annoying.
https://www.youtube.com/watch?v=70IxjLEmomg
https://en.wikipedia.org/wiki/Pre-established_harmony
XMonad of course, has windows.
And now for an actually funny joke about Leibniz:
http://existentialcomics.com/comic/108