-
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
Split Pane via a context menu #5025
Comments
Please link this from 1000. |
And yes, I love this idea. |
For the record, I've decided on this:
|
Ok. I was working on this a bit more. @DHowett-MSFT and I were thinking maybe the cleaner behavior would be to create a story for how to "move" a pane's configuration around. Think of it like dragging panes in VS Code and getting a shadow for where it would go. @zadjii-msft Thoughts? |
What if we did it on the tab context menu we added in #3789? |
Sorry, I don't follow. You'd right click on a tab, get the context menu, then what? |
Shoot, that's what I get for trying to reply to an issue on a vacation day from email. I'm thinking something like this, from VSCode: The "split right/left/up/down" that you get when clicking on a tab. I think that's also tracked somewhere in #1912 |
## Summary of the Pull Request Users can now open an auto split pane with the mouse. When opening the dropdown, alt+invoke the profile of choice and it should open in an auto sized pane. ## References #5025 - further discussion there as to whether this actually closes it. ## Detailed Description of the Pull Request / Additional comments Had to do a special check for debugTap because that's triggered by holding both alts. ## Validation Steps Performed alt+click/enter on a new profile. Looks great!
## Summary of the Pull Request⚠️ This spec has been moved from #6902. That version was branched off the new tab menu customization, and had a terribly convoluted git history. After discussion with the team, we've decided that it's best that this spec is merged atomically _first_, and used as the basis for #5888, as opposed to the other way around. > This document is intended to serve as an addition to the [Command Palette Spec], > as well as the [New Tab Menu Customization Spec]. > > As we come to rely more on actions being a mechanism by which the user defines > "do something in the Terminal", we'll want to make it even easier for users to > re-use the actions that they've already defined, as to reduce duplicated json as > much as possible. This spec proposes a mechanism by which actions could be > uniquely identifiable, so that the user could refer to bindings in other > contexts without needing to replicate an entire json blob. > ## PR Checklist * [x] Specs: #6899 * [x] References: #1571, #1912, #3337, #5025, #5524, #5633 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ [Command Palette Spec]: https://github.com/microsoft/terminal/blob/master/doc/specs/%232046%20-%20Command%20Palette.md [New Tab Menu Customization Spec]: https://github.com/microsoft/terminal/blob/master/doc/specs/%231571%20-%20New%20Tab%20Menu%20Customization.md
<!-- 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 Adds the Split Tab option to the tab context menu. Clicking this option will `auto` split the active pane of the tab into a duplicate pane. Clicking on an unfocused tab and splitting it will bring that tab into focus and split its active pane. We could make this a flyout from the context menu to let people choose horizontal/vertical split in the future if it's requested. I'm also wondering if this should be called Split Pane instead of Split Tab? <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #1912 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #5025 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] 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 * [ ] 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 https://user-images.githubusercontent.com/48369326/127691919-aae4683a-212a-4525-a0eb-a61c877461ed.mp4 <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed
🎉This issue was addressed in #10832, which has now been successfully released as Handy links: |
Description of the new feature/enhancement
If you have the dropdown open...
Alt
click a profile to open anauto
sized pane of the profile.related to #1000
Alternative Implementations
But why bother?
I'm a very visual person. I like to see what profiles I have before opening one, personally.
Also, I forget what each index for the new-pane key binding maps to which profile. So I constantly find myself opening a new pane, seeing that it's the wrong one, closing it, checking the drop down, figuring out the index, then trying the correct key binding. That's on me for being a very visual person, but being able to short-circuit the process into an alt+click would feel pretty natural, I think.
Proposed technical implementation details
This would be pretty easy to implement, actually. For input, we'd just look at how the Settings flyout menu is handled. Then we just call the new-pane function off of TermApp with the profile that we targeted.
If we go with the alternative implementations, the above implementation is fundamentally the same. We'd just call the function with different parameters.
Comments after #5928
#5928 added the ability to split pane by alt+clicking a profile in the new tab flyout. This doesn't entirely close this issue. Though now you can open a pane without keybindings, the user should still be able to choose whether they want a horizontal or vertical pane. This issue has been promoted to track that scenario in particular.
The text was updated successfully, but these errors were encountered: