For me, XMonad came close (at least at first, nearly every time I wanted some functionality, someone would have already implemented it in the xmonad-contrib packages). As my interests became more specific, I still ended up programming quite a bit over a few months, but for the basic, first-week config, it was largely just a matter of adopting examples found online.
When I first started XMonad, the first thing I configured was to make sure it ran on xfce, that I could use the mouse for selection/resizing, and that I could use the xfce panel (complete with a "panic button" I could click to close xmonad and restart xfwm). Nowadays, I would also add a virtual machine with frequent snapshots for config testing. These helped me to bypass the "accessibility" issue: I was able to feel relatively calm despite starting an "advanced" WM with an often dense programming language. Despite that I rarely ended up actually using the mouse or panic button, I think they helped in the first crucial periods, which allowed me to ease into the config and paid off in the long-term.candyjack wrote:If you're coming from a floating WM, the most accessible WMs are awesome and bluetile, which do most things right but, unfortunately, are both rather buggy (especially awesome)...Some WMs that are sanely coded include i3, herbstluftwm, and ratpoison, but from here on you're giving up mouse control, the ability to minimize and proper alt-tab functionality, and you'll spend a lot of time on configuration (especially if you choose ratpoison). A lot of getting used to, in other words.
Some of your complaints seem pretty weird, so I have to ask:
candyjack wrote:
- There is no alt-tab switching. This is an absolute necessity to me, as all other ways to window switching tend to be overly complex. It's the only way I know of to quickly way to switch between the most recent couple of windows, without any setup.
- For what kind of tiling WM is "most recent couple of windows" the most straightforward way of switching, much less an "absolute necessity"?
In XMonad, at least, the more "natural" way is probably to promote the most recent windows to the master or nearby, so that they're already visible - like an alt-tab prompt that's always there. Whenever I want to switch to, say, the third window, a focusdown focusdown (and possibly promote to master) is then pretty straightforward, without even a delay in scanning the separate alt-tab history popup.
Switching between the current and most recent window, I guess I could see being useful (although I've found I rarely use it in practice). Any deeper, though, requires either an alt-tab history menu or keeping the recent window history in your own brain stack, which is far less straightforward than using the navigation stack already present.
I suppose the less structured the layout, the more useful "recent window navigation" becomes (floating layouts, of course, being at the extreme of this scale). Structured navigation can rival alt-tabbing, however. More advanced techniques such as "focus on window(s) of the classname 'Firefox'", likely even quicker. - Why the particular key combo, alt-tab?
I did have the same alt-tab withdrawal at first, and binding some expected key to it was probably the first thing I did. It quickly became evident, however, that alt-tab required a fairly lengthy hand motion, and I suspect the only reason I ever got into it was familiarity. I'm plenty faster now with my current setup.
On the contrary, if an important function were bound to alt-tab by default, I would probably move it away to a closer key combo.
Even if true, you say that like it's a bad thing. Ahem, you do realize that the clutter doesn't go away just because all the windows are on the same workspace, right? Whatever window selection scheme you're using, whether alt-tab or listing on panels or fuzzy finding, is at least equally cluttered (and probably moreso, since the selection is over all windows, rather than just a single workspace of them).candyjack wrote:
- Windows can't be minimized. Instead, you have to spread them all out among virtual desktops / tags / whatever you want to call them, and get perturbed as all your desktops soon become cluttered.
I remember my old alt-tabbing habits, in particular, were absolutely terrible. It was not uncommon to alt-tab over literally 20 or 30 windows. Subdividing into workspaces of a few windows each is much better.
To be blunt, this sounds less like a problem with a WM than a problem with not being able to settle on a WM.candyjack wrote:
- It's just a lot of fiddling in general. I've been switching back and forth between WMs for years now, I've tried almost all of them, including obscure stuff like clfswm and yeahwm, and I'm still not satisfied.
One could make an analogous argument for staying in the status quo for anything ("if you switch from {whatever you're currently using}, you might switch again and again, wasting a lot of time in the process!"). Should we, therefore, never switch?
Also, I'm just not feeling it. It's still early days for me, but aside from passing curiosity, I haven't yet found a reason to try other WMs. On the contrary, getting XMonad to increasingly work the way I want it to has been quite satisfying, especially after the tricky bits. (That said, it comes with many ups and downs and we aren't 100% guaranteed to succeed in the end.)
Okay, this is a good point. A strangely good point, in fact, since I do the same thing, and now that you've pointed it out, I'm not entirely sure how it hasn't been an issue.candyjack wrote:
- Many cannot (fully) be controlled with the mouse alone (which is annoying if you're like me and you use one hand to eat).
I think, for me, it's been two things:
- I've made sure the mouse can be used for basic things like clicking to focus on windows, and the xfce4 panel allows me to click to the start menu or to focus on workspaces. Can't do anything else, but:
- My setup can actually do everything with one hand. Not conveniently (it actually alternates hands a lot), but it's been enough for my limited usecase while eating.
Fun fact: XMonad's StackSet has been proven never to crash with a pattern-match error:candyjack wrote:
- They are buggy as hell. Given, almost all GNU/Linux WMs are buggy, but tiling WMs are so especially.
Considering the amount of shoddy, memory-unsafe C we accept into our lives, I'd put the Haskell program that has gone through a proof checker pretty high up my listNeil Mitchell wrote:Dons recently asked me to look over the StackSet.hs module of XMonad, checking for pattern-match errors, using my Catch tool. This module is the main API for XMonad, and having a proof of pattern-match safety would be a nice result. I performed an initial check of the library, including introducing the necessary infrastructure to allow Catch to execute, then sent them the required patches. After I had given them the Catch tool and the initial results, sjanssen picked up the results and went on to modify the code further - with the end result that now StackSet will never crash with a pattern-match error.
Seriously though, yes, there are bugs. In fact, I ran into a particularly terrible bug with my later configuration, that would permanently grab the keyboard/mouse, requiring a restart. All I can say is that the virtual machine has been a lifesaver in allowing me to take a snapshot before testing, in order to instantly revert afterwards if I faced a problem.
So that experience was pretty annoying. Speaking broadly, however, what's the alternative? If you don't want to program the WM's behavior, then either you get really lucky with $DEVELOPER's wishlist matching your own and being bug-free (unlikely no matter how much WM-hopping) or you go with very coarse defaults. If you do program the WM's behavior, it's no longer standard and you open up the possibility of encountering an issue (as even the "once it compiles it usually works" Haskell can't fix an incorrect algorithm).