Comment by greggman2 | Hacker News Reader

Comment by greggman2 | Hacker News Reader

I have never enjoyed the distinction between apps, app windows, and in app windows. 25 years of alt+tab/Ctrl+tab/cmd+tab and I still can never switch to the thing I want. My mind is stuck on one hotkey that I want to mean "switch back to the last thing I was looking at" but that doesn't work because if the last thing was another app or another tab or window in the same program then I would need a different key. My brain doesn't want to have to remember that. it just wants "back to the last active thing" whatever that thing was.

this bite me every day for 25 years . example on desktop. I switch tabs by clicking a tab. want to back to the last tab. I do the "one" action (cmd-tab) and get a different app instead of the last tab. so it's cmd-tab again and then click the tab. Sometimes I press cmd-tab multiple times before my brain realizes I need to click a tab.

I'm often switching between editor (or 2), terminal, browser, and apps so this idea that I have to always no the exact state I'm and deliberately consciously pick one of 3 different key combos to switch seems crazy to me.

The same thing happens on mobile. swipe up and pick previous window is my action to get back to the previous thing so when I want to switch back to the previous tab I always without fail by swiping up and then curse that the device didn't do what I want and instead I need to click the "display tabs icon". Again I'll be juggling multiple apps so the fact that the thing I want "go back to last thing" is inconsistent always mean the ux is failing me

Amen. OS app/window distinction sucks because the OS doesn't really know what users experience as an app. We might have a dozen apps open inside chrome, or the same IDE configured for two massively different tasks.

Now that users juggle not just multiple apps and windows, but tabs and accounts and devices, the OS should stop pretending it's privy to our workflow - or give us a better way to configure it.

I agree the OS doesn't know what the app is doing with it's tabs/windows but the OS could mandate that it tell the OS a list of things the user should be able to switch to and design the API in such a way that we'd get a LRU behavior.

I can dream haha.

Just tried turning on tab support in Witch but AFAIK it can't do LRU so it's not helpful (T_T)

The thing that really gets my goat is the behavior with apps spread across multiple workspaces. Alt-tabbing on one workspace does not stay on that workspace but may switch to another app's window on another workspace. End of the day, I just use my MBP for Word (oh how the tides have turned) and VPN.

Oof, I know that pain. Or a similar one. I use the tiling window manager i3 - so I don't have windows stacked on top of each other to flip through, but I do have plenty of workspaces to flip through.

I wrote a small thing to help me manage creation and navigation of named i3 workspaces using dmenu (and I love it) but the first improvement I made was to add the ability to flip between the two most recently used workspaces and bind it to Alt-Tab. This immediately drove me up a wall by jumping to workspaces on different outputs (laptop screen, external monitor, etc) which was correct but remarkably disorienting. The next improvement was to make toggling only consider workspaces currently on the focused output. [0] I'm quite happy with the result (though there are still some bugs involving tracking workspace age while shifting them around between outputs).

There is a further improvement I'd love to add but don't know how - I want the Windows Alt-Tab behavior where Alt-Tab enters a "switching mode" and then as long as Alt is held down, repeated tapping of Tab fires an action (in this case, cycling focus to older and older targets). I haven't been able to find a key binding program or recipe that supports this kind of interaction (I'm currently using sxhkd).

0: https://github.com/mosbasik/fluidspaces-rs/blob/dev/src/bin/...

Reply on news.ycombinator.com