In essence, this is similar how I setup and use Spaces on macOS. Have a number of spaces that are horizontally laid out with a three finger left/right swipe between them.
For each Space, you can make the apps full-screen or split screen to have variable width windows. Of course you don't need to make them full screen but it does keep it simple similar to Cardboard.
The added functionality with this approach is that you can use the Space as a casual grouping of windows in a related project.
MacOS windowing is so hard for me to use though. I though I'd set my tmux in one window, browser in another, and everthing else in another.
However, randomly my windows focus in the wrong space, if I plug in another monitor all hell breaks loose.
Recently there's a weird bug where if I press the button to open spaces (ALT in my case), when I click back into iTerm, iTerm reduces it's size instead of staying fullscreen.
I switched to Gnone on my desktop, and that behaves exactly how I'd imagine it would work, but MacOS just seems to do it's own thing constantly.
Is it possible to disable the animation when switching between spaces? It’s something that has always prevented me from using such a setup. I’d rather have instant switch, considering how often I would perform this action.
If you use the three-fingers gesture, the animation is as fast as you can swipe. I don’t know if you can disable it when you use the keyboard (because I don’t).
tbf, i like the way it’s synced with the trackpad gesture : it allows you to start swiping left to just see something without interacting and go back to the right without leaving the trackpad to get back where you were. That’s pretty useful when you have running things that you care are ok but are not worth the real estate (logs, running dev server …)
There is the "Reduce motion" accessibility option (in the Display section) which turns the animation into a fade instead of a swipe. Not instant, but it might be a bit faster.
> The added functionality with this approach is that you can use the Space as a casual grouping of windows in a related project.
The cool thing about this is how well this mixed approach copes with the command-tab switcher; you stay local to the space until you tab to a thing that is in another space, which can make for really useful working patterns if, for example, you use site-specific browser apps for different online roles.
For me it is regularly VS Code full screen in one space, browser and another app (Apple notes, a messaging app or tailed server log in terminal) together on another.
But the difference between how Spaces works and how the WM in the demo video works seems like night and day.
For all my frustrations about the way changing the app in one half of a Space can work [0], the Apple interface is at least an attempt to produce something that is driven by obviousness and gestures, in the way that (as a veteran mac user can tell you) that the "menu bar across the top of the screen" model is more instinctive and quicker to interact with than each modal having its own menu.
The system in the demo video is jerky, hyperactive and surprising.
I'd rather accept the limitations of a simpler approach designed to avoid level of surprise and jitter.
[0] Not as well as iPadOS does. Never thought I'd say that sentence.
In particular I've found that using one Space per Jira ticket is a great way to juggle multiple ongoing tasks at once. Each gets its own code editor and Chrome window, with the ticket, merge request if applicable, any relevant research tabs, etc
Unfortunately macOS still doesn't let you name Spaces, but I figured out you can just create a text edit window, make the font gigantic and put it in the middle of the screen, and it can be readable from Mission Control
fullscreen windows, one per workspace (or multiple ones if that makes sense because i need them together)
on macos i scroll horizontally, on gnome vertically. (although newer gnome now also does horizontally by default, haven't checked how to change that)
the only problem i have is that i want to be able to scroll independently per display. i don't know if macos can do that, but gnome for sure can't. (it appears paperwm referenced in the article does that)
I have [Messages/Slack/Chrome | Outlook/Notes/Chrome | iTerm3/Chrome] setup and easily swipe between them. Chrome is fixed in place on all of them b/c I frequently refer to websites while doing Slack/Outlook/coding work.
iTerm3 is running tmux, connected to my remove development env (I'm a Neovim person, no local IDE needed).
All those apps are tiled at full size, on a wide-screen monitor. It's a great way to organize based on task (chat, email, code) and easily switch between them.
I used to do something like that on Gnome, except the touchpad gestures. I used Super-Alt-Left and Right.
Then I realized that I grouped windows in one desktop per customer. So I assigned a hotkey to each desktop and I switch by Super-letter. I don't have to cycle through multiple desktops to reach the one I need. That would be useless.
This is reminiscent of Gnome's PaperWM [0]. Not a Gnome user and just had the chance to try it for less than an hour, but the experience in my head sounded better than it was in reality - though was more of 'unexpected behavior' things than faults in the concept.
I think this approach tries to solve the 'cramming too much windows in a single virtual desktop' that sometimes can be felt with tiling WMs. For example, when I'm drawing something in Krita I'd want to see some references of what I'm drawing - I'd just scroll a bit to unveil an adjacent Falkon window to browse some images on the internet, do some strokes and scroll back to Krita's window - without having to resize it in half.
Perhaps I'm an outlier but PaperWM is one of the things I miss most dearly about Linux. (I'm on Mac/Win for now) I daily drove PaperWM for months and thoroughly enjoyed it. Quirks were noticed but ignorable, in particular I could not get multiple monitors to work as advertised.
Unexpected behaviour is exactly the problem -- I can see a lot of potential for it in the demo in the video, which is hard to follow.
Not to mention the serious problem with scrolling-within-scrolling. One of those windows could be a browser window, sized too thin so its content scrolls horizontally as well as vertically, and some of the content inside that browser window might scroll vertically or horizontally or both -- perhaps a textarea. Can the UI ever make it clear enough what scroll action is going to be triggered, or will there be a situation where you want to scroll one aspect but end up scrolling the whole desktop?
It's better to keep scrolling _out_ of a design, and it's surely better to switch context whole apps at a time, and not have them half-off the screen (which is the exact sort of occlusion irritation that tiling window managers are meant to avoid, surely?)
Well you can just have different scrolling, eg hold the super key and scroll with the mouse or use four fingers at once on a trackpad. I feel like this is asking the question of whether the TAB key will indent or switch controls or switch to a different window or whatever when you have an ordinary wm.
This leads to the kind of unexpected behaviour I am talking about, where muscle memory gets tangled up or you're working quickly and you do the action you want for one scroll while accidentally still holding down the modifier key.
When there's scrolling at so many levels in e.g. web content, binding yet more things to different modified scrolling motions is a bad idea.
If gestures work (big if, in my experience, in a system that unless something has changed really recently still has less than stellar trackpad implementations) then it would be less painful.
> I feel like this is asking the question of whether the TAB key will indent or switch controls or switch to a different window or whatever when you have an ordinary wm.
Not something that troubles me in ordinary apps on the Mac, at all (because app switching is command-tab) but I concede that this is regularly aggravating on the web.
Scrolling the desktop is accomplished through keybindings, clicking the screen edges, or three-finger swipes, all of which are configurable. I'm not sure how it would interfere with in-app scrolling, and I use PaperWM primarily.
I've sadly had a similar experience with System 76's Pop Shell[0]. That said I suspect graphical workloads and applications designed around conventional sizes and aspec ratios are generally not well suites for TWMs.
So I have very mixed feelings. On the one hand, super cool; this is the first time in a long time I've actually considered switching away from i3, because this seems like a natural fit for how I actually want to work. On the other hand, Wayland decided that each and every compositor is responsible for everything, so AFAICT cardboard can only handle QWERTY right now, and that's a complete non-starter for me.
And it looks like that makes it easier for the devs to support switching layouts, but AFAICT wlroots doesn't directly expose anything I can tweak as a user. I tried searching the web, hoping it read an environment variable or such, but couldn't find anything. Did I miss something?
(And as a general comment, even if wlroots did make this uniformly work, that only helps for compositors that use wlroots; with X, I could just tell the X server to switch layouts and it would work with every single window manager in existence.)
Well that just means wlroots is the standard in the sense you had with X, not Wayland. I too consider this unfortunate and a weird design choice, but at least we have this option on stabilizing on wlroots and ignoring everything else as something completely separate.
Er, on my laptop? It might be more precise to say that I can't find any way to make it use anything else; manpages give me nothing, grepping for "layout" in the source tree gives me nothing (relevant; window layouts show up), and there's an open issue (https://gitlab.com/cardboardwm/cardboard/-/issues/30) asking for it, all of which makes me conclude that it doesn't appear to support doing anything but QWERTY. That said, I said "AFAICT" for a reason; if you can prove me wrong I'll be quite grateful (because, seriously, I would like to use this thing).
Oh I think I understand what you're saying now. You have a laptop with a QWERTY hardware layout, and rely on the WM to remap the keys to a different layout? Sorry I can't help out. Just wanted to understand the issue.
Basically, yes. The hardware is QWERTY, and something in software has to be fiddled with to get my preferred layout - on Linux console that's loadkeys, in X11 it's setxkbmap or a config file, other systems do their own thing. The annoying thing to me is that in X11, the X server (usually Xorg) was the single point of configuration, and setxkbmap would work with any window manager without any special support needed; in Wayland, the compositor replaces Xorg and the window manager, so every single compositor has to do its own support for changing keyboard layout. As a sibling comment notes, wlroots appears to make this easier to implement, but as far as I can make out (I'm not much of a programmer) the dev still has to actually wire it up to do that, and cardboard doesn't seem to have done so. In the general case, I'm annoyed because the end result is that even if everyone did implement it, every single compositor would have its own special setting, when before I could either run setxkbmap or set it in the Xorg configuration file and it would work regardless of what window manager I happened to be running today.
A tiling window manager is one thing I still miss on MacOS from Linux. Back then I used ion3, I still think about it fondly.
I've been eyeing yabai [0] for a while. It requires system integrity protection to be disabled. I initially misread it as being fully disabled, but it turns out once whatever extensions are injected, protection can be reenabled. Excited to try it once it's got a Monterey version.
Have you looked at Magnet? Adds some tiling functionality based on drag-to-the-edge snapping, and installs right out of the Mac App Store. Not expensive either.
I previously used Yabai, but switched to Rectangle [0] as it doesn't require SIP to be disabled. It's not automatic with its tiling, it needs some direction but it provides a nice 'best-of-both' kind of approach.
re-enabling only works on Intel so I had to drop it :( Amethyst is the only alternative I know of but I am still trying to get it to use the shortcuts that I want.
Counterpoint: Amethyst is not great but it's also not Amethyst's fault. It does the best it can with MacOS's limited API support (really, using "accessibility" APIs, not windowing). Compared to i3 and other "standard" tiling WMs, you can't even really call it a tiling WM.
- The shortcuts are hot garbage
- Excessive windowing chrome everywhere takes up screen real estate
- Tree hierarchy of windows/containers (e.g. horizontal box of vertical boxes of windows) is not possible/practical
- Responsiveness to manual window manipulation is not great.
I keep it installed because MacOS's default keyboard support for windowing is far worse, borderline unusable compared to Linux options. It sets the wrong expectations to talk about Amethyst (or MacOS in general) in the context of tiling WMs.
Was very excited to see this idea, some time ago I was very excited by the thought of pretty much this same concept without the smooth scrolling, because I knew it could be done with some scripting in some other tiling wm that did "desktops" or "tags" on the fly.
And then I saw Wayland. Bleh.
So I'll ask -- anyone have any ideas, thoughts, pointers on doing something similar in X?
Ooh thanks. I switch between Openbox and AwesomeWM these days and had kind of forgotten about IceWM. Icesh seems tighter than the other stuff I've seen in this space.
Interesting take, but I can't see much use for it perhaps. I'd probably prefer vertical scrolling, and to be frank I did something like this a long time ago by setting my Xorg screen settings to be larger than my monitor (and then scrolling around with the mouse). Tie that with a tiling window manager like awesomeWM so that you can configure while you work and it should work out to be just about the same experience.
Highly appreciative of people trying new things though, I will never shut down people's desire to experiment. More power to them I say, one day someone might stumble into something that really really works wonders.
edit: sorry, I thought the project WAS PaperWM. but no it's cardboard that has been inspired by PaperWM.
Maybe this is a bit of a ridiculous idea, but what about natively supporting tabs in a window manager? While it would probably be impractical to force all applications to support tabs, it would be nice to be able to rearrange elements/windows of work/productivity apps as such.
This is not that far from the way macOS does it, where apps can go full-screen as if they were single-app virtual desktops.
You can flick between the apps, but the useless situation where apps are half-off the screen, like the wretched Metro interface on Windows, does not occur.
A lot of tiling WMs, for example i3, already support that. It can be useful when you want to hide a window like a long running terminal session, but I usually go to a new virtual desktop instead
For Windows, Groupy is a utility to group and tab windows. Works well with the built in snapping of Windows. Buy it on Steam and you can use it on up to five computers IIRC.
I used one of those leap motion controllers once, but then I spent a few minutes watching someone else use one and I realised several things that seem equally important to me:
1) moving your hand away from a keyboard to perform gestures not that much richer than a trackpad isn't as transformative as it seems, or very efficient
2) how they feel to interact with does not balance well with how they look to interact with, away from a gaming type context. How it feels: peculiarly magical, like casting spells. How it looks: D&D wizard excitedly miming his spells at the table-top, to the annoyance of his party.
3) there's really very often a beverage on my desk in a way that is at odds with me -- a clumsy type -- waving my hands around enthusiastically.
The only use I ever really found for my Leap was to control iTunes when I was in the middle of bleaching or dyeing my hair and didn’t want to touch the keyboard. It was great for that.
I say “was” because the tool I was using for this no longer supports the Leap.
I'd be happy to wave gestures for stuff that people normally use Alexa/Siri for, because while I talk to myself out loud all the time, talking to a computer is weird.
But it's fascinating isn't it how the Leap was going to be everything and then within a year or two it's discounted in Maplin.
On macOS you can easily tile pairs of apps on a single virtual screen and switch between virtual screens with a gesture. But you always know you're on a particular screen; it's all or nothing.
Arbitrary scroll left and right with arbitrary window widths is going to be tiresome, and good luck keeping up with what the window manager in that demo is doing when you're tired.
Scrolling automatically to the window that has focus? Narp. Applications that are half off the screen? Why? It's just extra cognitive load.
Personally I'd like it a lot. I think applications half of the screen can make sense. It'd be great to use to place things off screen that I may not need to use actively like Chrome devtools.
Accessibility is an issue though. If i could three finger scroll context horizontally that would be nice.
But isn't having things positioned half-off the screen one of the traditional overlapping-window manager patterns that tiling window managers are meant to avoid?
Notably a very nice, somewhat newspaper-like choice of line-length, line-spacing, and paragraph margins, which make quick reading easier (which might be part of what you mean by non-distracting)
> The WM isn’t suitable for day-to-day use by most users. It doesn’t support drag-and-drop and other features most people would consider being necessities.
It's not entirely clear to me whether that's meant to say that the software is in a beta state, or that it uses a sufficiently different model that it will never be entirely suitable for a general audience (like rather many existing tiling window managers)
Since you're all downvoting me for simply having an unenthusiastic opinion, here is that opinion in detail:
we spend a lot of time designing applications so they don't horizontally scroll, and now you want your window manager to do it? What's wrong with full-screen applications in multiple virtual desktops like macOS?
> What's wrong with full-screen applications in multiple virtual desktops like macOS?
Sometimes you need to look at two–three windows at a time. Maybe four (a terminal) that can live sort of to the side of the main two–three windows. A scrolling VM lets you work more fluidly instead of forcing everything into a screen-sized box. It’s useful to have a note-taking app side-by-side with a document you work with or a webpage for research. (Not all apps are designed to be used fullscreen. E.g. a calculator.)
> Sometimes you need to look at two–three windows at a time.
You can actually tile two windows in a single full-screen (menu-less) view on macOS, and they can be sized arbitrarily as the two windows allow.
So for example you can do the editor/browser pair, or the file manager/preview pair. macOS doesn't get everything about the window selection process right, mind you, but this pairing approach does work pretty well.[0]
You can then swap (slide) between those full-screen views (and other ordinary desktop views) with a gesture, but because it snaps to full screens, you only need a simple swipe gesture.
Endless _arbitrary_ horizontal scrolling will get tiresome, having the window scroll as soon as the focus changes will be jarring at times, and having half the content of one or more windows off the screen at any one time will become cognitively frustrating.
[0] I find it very rare to need to tile four windows on a screen but surely ordinary window manager tiling mechanics can handle that (or Magnet, on the mac).
I am totally dependent on Spectacle. There are modern equivalent replacements, since the original is no longer supported. I can never understand why Apple won't build that functionality in.
(Dunno. Wasn't me! Still haven't used my downvote power... I don't really understand people's use of it at all. Have an upvote. It was a fair question.)
For each Space, you can make the apps full-screen or split screen to have variable width windows. Of course you don't need to make them full screen but it does keep it simple similar to Cardboard.
The added functionality with this approach is that you can use the Space as a casual grouping of windows in a related project.