feat(macos/gtk): keybind for accessing the last active tab #1869
Conversation
|
I might've missed it but it doesn't look like this takes into account when tabs are deleted, at least for GTK. Didn't look at macos |
Yes, it currently behaves naively and possibly incorrectly by attempting to navigate to a pane that does not exist. Open to feedback here on the expected behavior. |
|
Looks pretty good so far. I think the major issues that need to be worked out before I can merge:
Otherwise the core plumbing all looks very good to me! I'm happy to take a look at this soon if you don't get to it. |
For this one, I am happy to accept help in the form of commit(s) or links to relevant parts of the code. Alternatively, I can read through the source and figure it out independently; it will take a bit longer as I am learning Swift/Macos app dev.
What behavior do you think is the most intuitive? The current active tab?
Thank you and a bigger thank you to @kdrag0n for giving me a commit to cherry-pick. |
I think you probably need to maintain a stack where the length of the stack is the number of tabs. When a new tab is focused, find its old position in the the stack, and move it to the front. This would be similar to how tmux works. I'm not sure what a tab group is on Mac, but you might just need to maintain a stack per tab group or a stack that can span tab groups. |
|
I'd be fine simplifying this logic so that the "last active tab" is only valid so long as that tab remains valid. Once you close it, your last active tab is gone so the key bind does nothing. I don't think we need a full "back/forward" or "undo/redo" style logic here. |
KVO on tabGroup.selectedWindow works but I can't figure out how to detect when the tabGroup changes, so the observer gets attached to the wrong tabGroup TODO: lastActiveTabIndex needs to be per-tab-group, not global, but I can't figure out how to store per-tab-group or per-associated-window state
SkamDart
force-pushed
the
last-active-tab-keybind
branch
from
a9187bb to
0d5067a
Compare
|
What happened to this PR? Will it be revived? |
Resolves #1844
Tested on both aarch64-darwin and x86_64-linux (NixOS)