-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scenario: Add support for panes #1000
Comments
* Start working on adding support for panes See #1000 for the panes megathread on remaining work. The functionality will be there, but the keybinding won't be there, so people have to opt-in to it.
We didn't commit the keybinding constants in with which people could opt. |
I noticed that @zadjii-msft added the keybindings for panes back. I'm assuming it made it into 0.1.1621.0? If I add this block:
Only Horizontal works. I noticed that if I close |
@decriptor I believe that's because '|' isn't actually a key we support in the keybindings quite yet - see #1212 |
@zadjii-msft I believe you are right. I used |
I know you really want it, @zadjii-msft but you have #998 on your list twice ;-) |
@Jaykul good catch, those are supposed to be separate issues. |
@zadjii-msft and @Jaykul - just let me know where to send the care packages (hoppy beverages / candy / beef jerky / etc) 😆 Cannot wait for panes to be implemented! |
Any chance of getting "focus follows mouse" like in iterm2 and other terminals? So if this setting is turned on, the active pane would be the pane you have your mouse pointer over, without having to click it first. |
I wrote a startup script which chains multiple Can I convice wt somehow to also split the left or top right pane? As you can see the resulting segmentation is neither ideal, nor what all users want. If not, is there a feature request for that? |
@Trolldemorted as is mentioned in the OP:
|
#4340 would allow me to specify whether I want to split the right or left pane, but not to split both, right? |
Ah yes. What about #3759? |
Depending how they solve it it might partially cover that, but it won't cover the "commit a batch script in your repository which starts wt in a grid layout" use case, correct? Every user would have to create a profile manually, or we'd have to touch the users' profiles in our batch script. |
So, #4340 "Choose Direction to Split Pane" might be helpful yes, but then you'll still get stuck splitting panes down just one branch of the tree. What you really want is probably #6580, which will let you Also maybe helpful in the future:
|
Thanks @zadjii-msft ! Let's hope #6580 will make it to the roadmap soon. Can I specify an initial command for the shells somehow? Right now I am using |
Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References #1000 Closes #2871
Adds a "move to previous pane" and "move to next pane" keybinding, which navigates to the last/first focused pane We assign pane IDs on creation and maintain a vector of active pane IDs in MRU order. Navigating panes by MRU then requires specifying which pane ID we want to focus. From our offline discussion (thanks @zadjii-msft for the concise description): > For the record, the full spec I'm imagining is: > > { command": { "action": "focus(Next|Prev)Pane", "order": "inOrder"|"mru", "useSwitcher": true|false } }, > > and order defaults to mru, and useSwitcher will default to true, when > there is a switcher. So > > { command": { "action": "focusNextPane" } }, > { command": { "action": "focusNextPane", "order": "mru" } }, > > these are the same action. (but right now we don't support the order > param) > > Then there'll be another PR for "focusPane(target=id)" > > Then a third PR for "focus(Next|Prev)Pane(order=inOrder)" > for the record, I prefer this approach over the "one action to rule > them all" version with both target and order/direction as params, > because I don't like the confusion of what happens if there's both > target and order/direction provided. References microsoft#1000 Closes microsoft#2871
"#6459 Pane focus follows mouse" can be checked off the list, a fix for it has been merged a while back. |
@JelteF Thanks! Cleaned that up a bit |
Hi, There are option to move panes like tmux ? |
…2) (#10638) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This work potentially touches on: #1000 #2398 and #4922 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes a component of #1000 (partially, comment), #4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality) * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes. Work currently done: - Add boilerplate/infrastructure for argument parsing, hotkeys, event handling - Adds the `MovePane` function that finds the focused pane, and then tries to find a pane that is visually adjacent to according to direction. - First pass at the `SwapPanes` function that swaps the tree location of two panes - First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus` that search the tree for the currently focused pane, and then climbs back up the tree to try to find a sibling pane that is adjacent to it. - An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction. Next steps: - Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve #2398 by updating the `NavigateFocus` function. - Do we want default hotkeys for the new actions? <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
…2) (microsoft#10638) <!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Add functionality to swap a pane with an adjacent (Up/Down/Left/Right) neighbor. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References This work potentially touches on: microsoft#1000 microsoft#2398 and microsoft#4922 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes a component of microsoft#1000 (partially, comment), microsoft#4922 (partially, `SwapPanes` function is added but not hooked up, no detach functionality) * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [x] Schema updated. * [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Its been a while since I've written C++ code, and it is my first time working on a Windows application. I hope that I have not made too many mistakes. Work currently done: - Add boilerplate/infrastructure for argument parsing, hotkeys, event handling - Adds the `MovePane` function that finds the focused pane, and then tries to find a pane that is visually adjacent to according to direction. - First pass at the `SwapPanes` function that swaps the tree location of two panes - First working version of helpers `_FindFocusAndNeighbor` and `_FindNeighborFromFocus` that search the tree for the currently focused pane, and then climbs back up the tree to try to find a sibling pane that is adjacent to it. - An `_IsAdjacent' function that tests whether two panes, given their relative offsets, are adjacent to each other according to the direction. Next steps: - Once working these functions (`_FindFocusAndNeighbor`, etc) could be utilized to also solve microsoft#2398 by updating the `NavigateFocus` function. - Do we want default hotkeys for the new actions? <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed At this point, compilation and manual testing of functionality (with hotkeys) by creating panes, adding distinguishers to each pane, and then swapping them around to confirm they went to the right location.
Instead of `Pane` hosting a `TermControl` directly, it now hosts an `IPaneContent`. This is an abstraction between the TermControl and the pane itself, to allow for arbitrary implementations of `IPaneContent`, with things that might not be terminals. ## References and Relevant Issues * #997 * #1000 ## Detailed Description of the Pull Request / Additional comments This PR by itself doesn't do much. It's just a refactoring. - It doesn't actually add any other types of pane content. - It overall just tries to move code whenever possible, with as little refactoring as possible. There are some patterns from before that don't super scale well to other types of pane content (think: the `xyzChanged` events on `IPaneContent`). - There's a few remaining places where Pane is explicitly checking if its content is a terminal. We probably shouldn't, but meh There are two follow-up PRs to this PR: * #16171 * #16172 In addition, there's more work to be done after these merge: * TODO! issue number for "Replace `IPaneContent::xyzChanged` with `PropertyChanged` events" * TODO! issue number for "Re-write state restoration so panes don't produce `NewTerminalArgs`" ## Validation Steps Performed * It still launches * It still works * Broadcasting still works * The weird restart connection thing from #16001 still works ## PR Checklist - [x] Closes #997 ## other PRs * #16170 <-- you are here * #16171 * #16172
This is the megathread for tracking all the work related to Panes in the Windows Terminal.
1.0 Features
1.0 Features
tmux
accomplishes this by colorizing the separators adjacent to the active pane. Another idea is displaying a small outline around the focused pane (like when tabbing through controls on a webpage). (PR:Indicate which pane is focused with the Accent color on the pan… #3060)1.x features / bugs
2.0 Features / Bugs
moveFocus
to pane using number (See also Add support forfocus-pane
subcommand #5464)requestedTheme
, follows system app mode #3917 Panel split background ignoresrequestedTheme
, follows system app modepercent
parameter toSplitPane
Add apercent
parameter toSplitPane
#3997nextPane
andprevPane
keybindings (in PR Support for navigating panes by MRU #8183)Panes Titlebar Follow-ups - See #4998
Backlog items
tmux
Control Mode #3656 Add support fortmux
Control ModeswitchLeft
,switchRight
,switchUp
,switchDown
, to allow the user to rearrange the panes layout (Scenario: Add support for panes #1000 (comment)) (Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) #10638)moveFocus
keys when the user has no panes #6219 Pass throughmoveFocus
keys when the user has no panesTheming items
(PR Enable changing the color of the active pane border #3752)The text was updated successfully, but these errors were encountered: