Twitching between apps of different workspaces

[humdinger]

This is hrev54249.

Was this always like this? :

• Go to workspace 1
• Open apps A and B
• Switch back and forth between A and B by holding CTRL and tapping TAB.

So far, so perfect. Now:

• Move app B to workspace 2
• Whaa? Now CTRL + TAB doesn't switch between A and B anymore...

It only works for apps on the same workspace. I don't think that's right.

[bipolar]

I tend to use different workspaces for different "activities", even if I have the same app open in multiple workspaces.

That way, switching betweeen windows only on the same workspace makes sense (to me), unless you want to switch "activity/task". In that case, you just switch workspaces first, and presto.

Say I'm working on Project A on Workspace 1 (couple of Pe windows open, some Tracker ones, plus Terminal). Similar windows on Workspace 2, but working on Project B.

For that workflow, jumping around Workspaces while switching apps would be kind of annoying, I think.

---

What I would do like if that when you switch workspaces (say, by clicking in the Workspaces' Deskbar replicant), the top most window would get the focus, instead of the current situation where the focus goes... where? Deskbar?

---

What prompted me to write this comment, was reading ​https://review.haiku-os.org/c/haiku/+/6304

[humdinger]

Yeah, i can see how both behaviours are correct and wrong at the same time... A twitching superposition. :) Not sure it's possible to collapse that wave function to everyone's pleasure.

[anevilyak]

I'd personally also prefer to keep the existing behavior, because that's exactly what I use workspaces for as well. If twitcher is going to just go on a wild ride across them, their whole organizational flow becomes pointless. I might note this is also the behavior on other systems I use that support virtual desktops, so keeping it restricted is more consistent there.

[humdinger]

If twitcher is going to just go on a wild ride across them, their whole organizational flow becomes pointless.

Well, it's not a total roller coaster. :) Tapping CTRL+TAB would only ever switch between the last and current application. That's at least somewhat consistent.

Say you have Web+ and Mail on workspace 1 and Koder and a Tracker window on workspace 2.
You work on ws2 for an hour, then quickly change from Koder to Web+ on ws1 for a quick look in the BeBook. Now CTRL+TAB doesn't switch back to Koder on ws2, but MAIL which was the app that was last active before Web+ on that workspace an hour ago.

Just saying. Always switching between current and last used app is quite predictable. And once you're back in the flow on your project workspace, switching back and forth between two apps on it requires one mousy operation at most, i.e. in this example, switching deliberately to the Tracker window with a mouse click when working in Koder again (because otherwise CTRL+TAB would switch back to the BeBook Web+ from before).

[anevilyak]

In your scenario, I would have the bebook in the same workspace since I'm probably going to need to frequently reference it. That said, if I do need to switch to an app that's in another workspace, I'll just have alt+fn to jump to that workspace and jump back, I really, really dislike the idea of twitcher adding that because it'd be slower, and as stated IMO its behavior would be suboptimal.

[humdinger]

Alright, I guess I'm not that organized. I often just move to a new workspace when the current one gets too crowded, and wouldn't know on which workspace exactly I've put Web+, for example. :)

Anyway, I guess I'll clarify the user guide on this...

[nephele]

What I would do like if that when you switch workspaces (say, by clicking in the Workspaces' Deskbar replicant), the top most window would get the focus, instead of the current situation where the focus goes... where? Deskbar?

The focus should go to the window you clicked, which'd be tracker most of the time.

This is incompatible with focus follows mouse though :)

[bipolar]

Replying to nephele:

The focus should go to the window you clicked, which'd be tracker most of the time.

My workspace replicant in Deskbar are too tiny for "click on that specific window" to be meaningful. I only click on the small rectangle representing the workspace I want to switch to, and not on a particular window there. Of course, for bigger replicants, setting focus on the clicked window makes sense :-)

This is incompatible with focus follows mouse though :)

Good thing I don't use that then :-P

[pulkomandy]

For reference, jscipione made a change implementing this: ​https://review.haiku-os.org/c/haiku/+/6304

In the discussion here and in the change, modifying the current behavior for CycleApp and possibly for QucikSwitch seems controversial. Someone already suggested adding a setting somewhere to allow either mode. Maybe before doing that, we should consider if adding more shortcut keys is a reasonable option.

We already have Control + Tab and Control + ~ (the key above tab), the latter cycles between all window for an app. Both are by default restricted to the current workspace. Would Control + Shift + Tab/~ be a reasonable way to reach the "... on all workspaces" versions of these? Is that a too complicated finger gesture? Is it already used for something else such as cycling backwards? (I don't see that mentionned in the user guide but maybe it would make sense to have it do that).

[nephele]

Why not just use alt-tab for that? I honestly fail to see why ctrl-tab was chosen, we are the only OS that I know off that does this and it gives me cramod. even macos used alt(command)-tab.

[jscipione]

Ctrl+Tab was chosen because it is swapped compared to Windows Alt+Tab.

[nephele]

So it really is just to be different? seems like a weak reason to me.

[pulkomandy]

If you set the keymap to use Windows/Linux style shortcuts, you get things exactly like on Windows/Linux: Alt for Alt+Tab and Ctrl for application shortcuts. This is probably how this was designed. And when you switch the BeOS/Mac style shortcuts, it gets swapped just like everything else.

There's no good way to avoid that unless we ban applications from using Command + Tab as a shortcut (it would clash with Twitcher then, but only in some keyboard configurations, which would be confusing).

[anevilyak]

Replying to jscipione:

Ctrl+Tab was chosen because it is swapped compared to Windows Alt+Tab.

It had nothing to do with Windows, ctrl was used because alt/cmd was reserved as the modifier for shortcuts, so to avoid clashing with apps, ctrl was used for the task switcher.

[nephele]

And when you switch the BeOS/Mac style shortcuts

That is exactly my point, MacOS uses alt-tab, not ctrl tab.

[pulkomandy]

Yes, but this was designed with Windows/Linux as a reference and then switched with everything else to avoid a shortcut conflict. We are over-constrained here, and not being compatible with MacOS is the constraint that was broken so the two others had a solution:

You can only get 2 of these 3 options:

• Shortcut in Windows mode is the same as on Windows (Alt+Tab)
• Shortcut in BeOS/MacOS mode is the same as MacOS (Atl+Tab)
• Shortcut changes between Windows and BeOS/MacOS mode to not risk a conflict with Command+Tab shortcuts that could be assigned by applications.

[nephele]

I'd just have both be assigned to the same thing.