2019-08-17 00:43:51 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
#include "pch.h"
|
|
|
|
|
|
|
|
#include "ActionArgs.h"
|
|
|
|
|
|
|
|
#include "ActionEventArgs.g.cpp"
|
Add support for new panes with specifc profiles and other settings overrides (#3825)
## Summary of the Pull Request
This enables the user to set a number of extra settings in the `NewTab` and `SplitPane` `ShortcutAction`s, that enable customizing how a new terminal is created at runtime. The following four properties were added:
* `profile`
* `commandline`
* `tabTitle`
* `startingDirectory`
`profile` can be used with either a GUID or the name of a profile, and the action will launch that profile instead of the default.
`commandline`, `tabTitle`, and `startingDirectory` can all be used to override the profile's values of those settings. This will be more useful for #607.
With this PR, you can make bindings like the following:
```json
{ "keys": ["ctrl+a"], "command": { "action": "splitPane", "split": "vertical" } },
{ "keys": ["ctrl+b"], "command": { "action": "splitPane", "split": "vertical", "profile": "{6239a42c-1111-49a3-80bd-e8fdd045185c}" } },
{ "keys": ["ctrl+c"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile1" } },
{ "keys": ["ctrl+d"], "command": { "action": "splitPane", "split": "vertical", "profile": "profile2" } },
{ "keys": ["ctrl+e"], "command": { "action": "splitPane", "split": "horizontal", "commandline": "foo.exe" } },
{ "keys": ["ctrl+f"], "command": { "action": "splitPane", "split": "horizontal", "profile": "profile1", "commandline": "foo.exe" } },
{ "keys": ["ctrl+g"], "command": { "action": "newTab" } },
{ "keys": ["ctrl+h"], "command": { "action": "newTab", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+i"], "command": { "action": "newTab", "profile": "profile2", "startingDirectory": "c:\\foo" } },
{ "keys": ["ctrl+j"], "command": { "action": "newTab", "tabTitle": "bar" } },
{ "keys": ["ctrl+k"], "command": { "action": "newTab", "profile": "profile2", "tabTitle": "bar" } },
{ "keys": ["ctrl+l"], "command": { "action": "newTab", "profile": "profile1", "tabTitle": "bar", "startingDirectory": "c:\\foo", "commandline":"foo.exe" } }
```
## References
This is a lot of work that was largely started in pursuit of #607. We want people to be able to override these properties straight from the commandline. While they may not make as much sense as keybindings like this, they'll make more sense as commandline arguments.
## PR Checklist
* [x] Closes #998
* [x] I work here
* [x] Tests added/passed
* [x] Requires documentation to be updated
## Validation Steps Performed
There are tests 🎉
Manually added some bindings, they opened the correct profiles in panes/tabs
2019-12-09 14:02:29 +01:00
|
|
|
#include "NewTerminalArgs.g.cpp"
|
2019-08-17 00:43:51 +02:00
|
|
|
#include "CopyTextArgs.g.cpp"
|
Add support for arbitrary args in keybindings (#3391)
## Summary of the Pull Request
Enables the user to provide arbitrary argument values to shortcut actions through a new `args` member of keybindings. For some keybindings, like `NewTabWithProfile<N>`, we previously needed 9 different `ShortcutAction`s, one for each value of `Index`. If a user wanted to have a `NewTabWithProfile11` keybinding, that was simply impossible. Now that the args are in their own separate json object, each binding can accept any number of arbitrary argument values.
So instead of:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": "newTabProfile0", "keys": ["ctrl+shift+1"] },
{ "command": "newTabProfile1", "keys": ["ctrl+shift+2"] },
{ "command": "newTabProfile2", "keys": ["ctrl+shift+3"] },
{ "command": "newTabProfile3", "keys": ["ctrl+shift+4"] },
```
We can now use:
```json
{ "command": "newTab", "keys": ["ctrl+shift+t"] },
{ "command": { "action": "newTab", "index": 0 }, "keys": ["ctrl+shift+1"] },
{ "command": { "action": "newTab", "index": 1 }, "keys": ["ctrl+shift+2"] },
{ "command": { "action": "newTab", "index": 2 }, "keys": ["ctrl+shift+3"] },
```
Initially, this does seem more verbose. However, for cases where there are multiple args, or there's a large range of values for the args, this will quickly become a more powerful system of expressing keybindings.
The "legacy" keybindings are _left in_ in this PR. They have helper methods to generate appropriate `IActionArgs` values. Prior to releasing 1.0, I think we should remove them, if only to remove some code bloat.
## References
See [the spec](https://github.com/microsoft/terminal/blob/master/doc/specs/%231142%20-%20Keybinding%20Arguments.md) for more details.
This is part two of the implementation, part one was #2446
## PR Checklist
* [x] Closes #1142
* [x] I work here
* [x] Tests added/passed
* [x] Schema updated
## Validation Steps Performed
* Ran Tests
* Removed the legacy keybindings from the `defaults.json`, everything still works
* Tried leaving the legacy keybingings in my `profiles.json`, everything still works.
-------------------------------------------------
* this is a start, but there's a weird linker bug if I take the SetKeybinding(ShortcutAction, KeyChord) implementation out, which I don't totally understand
* a good old-fashioned clean will fix that right up
* all these things work
* hey this actually _functionally_ works
* Mostly cleanup and completion of implementation
* Hey I bet we could just make NewTab the handler for NewTabWithProfile
* Start writing tests for Keybinding args
* Add tests
* Revert a bad sln change, and clean out dead code
* Change to include "command" as a single object
This is a change to make @dhowett-msft happy. Changes the args to be a part
of the "command" object, as opposed to an object on their own.
EX:
```jsonc
// Old style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": { "action": "switchToTab", "index": 0 }, "keys": ["ctrl+alt+1"] },
// new style
{ "command": "switchToTab0", "keys": ["ctrl+1"] },
{ "command": "switchToTab", "args": { "index": 0 } "keys": ["ctrl+alt+1"] },
```
* schemas are hard yo
* Fix the build?
* wonder why my -Wall settings are different than CI...
* this makes me hate things
* Comments from PR
* Add a `Direction::None`
* LOAD BEARING
* add some GH ids to TODOs
* add a comment
* PR nits from carlos
2019-11-14 23:23:40 +01:00
|
|
|
#include "NewTabArgs.g.cpp"
|
2019-08-17 00:43:51 +02:00
|
|
|
#include "SwitchToTabArgs.g.cpp"
|
|
|
|
#include "ResizePaneArgs.g.cpp"
|
|
|
|
#include "MoveFocusArgs.g.cpp"
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#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.
2021-07-22 14:53:03 +02:00
|
|
|
#include "MovePaneArgs.g.cpp"
|
Move Pane to Tab (GH7075) (#10780)
<!-- 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 move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
#include "SwapPaneArgs.g.cpp"
|
2019-09-30 15:18:05 +02:00
|
|
|
#include "AdjustFontSizeArgs.g.cpp"
|
2020-08-12 15:46:53 +02:00
|
|
|
#include "SendInputArgs.g.cpp"
|
2019-11-28 14:42:15 +01:00
|
|
|
#include "SplitPaneArgs.g.cpp"
|
Add keybinding arg to openSettings (#6299)
## Summary of the Pull Request
Adds the `target` keybinding arg to `openSettings`. Possible values include: `defaultsFile`, `settingsFile`, and `allFiles`.
## References
#5915 - mini-spec
## PR Checklist
* [x] Closes #2557
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
Implemented as discussed in the attached spec. A new enum will be added for the SettingsUI when it becomes available.
## Validation Steps Performed
Added the following to my settings.json:
```json
{ "command": "openSettings", "keys":... },
{ "command": { "action": "openSettings" }, "keys":... },
{ "command": { "action": "openSettings", "target": "settingsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "defaultsFile" }, "keys":... },
{ "command": { "action": "openSettings", "target": "allFiles" }, "keys":... }
```
2020-06-12 23:19:18 +02:00
|
|
|
#include "OpenSettingsArgs.g.cpp"
|
2020-08-10 18:21:56 +02:00
|
|
|
#include "SetColorSchemeArgs.g.cpp"
|
Add `setTabColor` and `openTabColorPicker` actions (#6567)
## Summary of the Pull Request
Adds a pair of `ShortcutAction`s for setting the tab color.
* `setTabColor`: This changes the color of the current tab to the provided color, or can be used to clear the color.
* `openTabColorPicker`: This keybinding immediately activates the tab color picker for the currently focused tab.
## References
## PR Checklist
* [x] scratches my own itch
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/69
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
* hey look there are tests
* Tested with the following:
```json
// { "command": "setTabColor", "keys": [ "alt+c" ] },
{ "keys": "ctrl+alt+c", "command": { "action": "setTabColor", "color": "#123456" } },
{ "keys": "alt+shift+c", "command": { "action": "setTabColor", "color": null} },
{ "keys": "alt+c", "command": "openTabColorPicker" },
```
2020-06-25 15:06:21 +02:00
|
|
|
#include "SetTabColorArgs.g.cpp"
|
2020-06-24 22:07:41 +02:00
|
|
|
#include "RenameTabArgs.g.cpp"
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
#include "ExecuteCommandlineArgs.g.cpp"
|
2020-10-15 13:40:44 +02:00
|
|
|
#include "CloseOtherTabsArgs.g.cpp"
|
|
|
|
#include "CloseTabsAfterArgs.g.cpp"
|
2021-06-25 21:22:52 +02:00
|
|
|
#include "CloseTabArgs.g.cpp"
|
2020-11-25 23:09:27 +01:00
|
|
|
#include "MoveTabArgs.g.cpp"
|
Add `findNext`, `findPrev` actions (#8917)
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results.
Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!
If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.
## Validation Steps Performed
I've played with it all day and it seems _crisp_.
Closes #7695
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
|
|
|
#include "FindMatchArgs.g.cpp"
|
2020-12-03 17:15:31 +01:00
|
|
|
#include "ToggleCommandPaletteArgs.g.cpp"
|
2021-02-20 00:51:30 +01:00
|
|
|
#include "NewWindowArgs.g.cpp"
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
#include "PrevTabArgs.g.cpp"
|
|
|
|
#include "NextTabArgs.g.cpp"
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
#include "RenameWindowArgs.g.cpp"
|
2021-04-29 00:13:28 +02:00
|
|
|
#include "GlobalSummonArgs.g.cpp"
|
2021-05-21 23:55:57 +02:00
|
|
|
#include "FocusPaneArgs.g.cpp"
|
2021-09-02 16:59:42 +02:00
|
|
|
#include "ClearBufferArgs.g.cpp"
|
Add action to run multiple actions. (#11045)
<!-- 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 a new action that can contain multiple other actions.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #3992
* [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
* [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
Creates a shortcut action that allows a list of actions to be specified as arguments. Steals a bunch of the serialization code from my other pr. Overall, because I had the serialization code written already, this was remarkably easy.
I can't think of any combined action to be added to the defaults, so I think this is just a thing for the documentation unless someone else has a good example. I know there are lot of times when the recommended workaround is "make an action with commandline wt.exe ..." and this could be a good replacement for that, but that is all personalized.
I didn't add this to the command line parsing, since the command line is already a way to run multiple actions.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Created a new command, confirmed that "Move right->down" showed up in the command palette, and that running it did the correct behavior (moving right one pane, then down one pane).
```
{
"command": {
"action": "multipleActions",
"name": "Move right->down",
"actions": [
{"action": "moveFocus", "direction": "right" },
{"action": "moveFocus", "direction": "down" },
]
}
}
```
2021-08-31 21:35:51 +02:00
|
|
|
#include "MultipleActionsArgs.g.cpp"
|
2020-06-26 22:38:02 +02:00
|
|
|
|
|
|
|
#include <LibraryResources.h>
|
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
using namespace winrt::Microsoft::Terminal::Control;
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
|
2020-10-06 18:56:59 +02:00
|
|
|
namespace winrt::Microsoft::Terminal::Settings::Model::implementation
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
winrt::hstring NewTerminalArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
std::wstringstream ss;
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Profile().empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"profile: {}, ", Profile());
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
2021-05-20 20:44:04 +02:00
|
|
|
else if (ProfileIndex())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"profile index: {}, ", ProfileIndex().Value());
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Commandline().empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"commandline: {}, ", Commandline());
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!StartingDirectory().empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"directory: {}, ", StartingDirectory());
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!TabTitle().empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"title: {}, ", TabTitle());
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TabColor())
|
2020-11-20 05:36:18 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
const til::color tabColor{ TabColor().Value() };
|
2020-11-20 05:36:18 +01:00
|
|
|
ss << fmt::format(L"tabColor: {}, ", tabColor.ToHexString(true));
|
|
|
|
}
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!ColorScheme().empty())
|
2021-03-29 22:04:39 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"colorScheme: {}, ", ColorScheme());
|
2021-03-29 22:04:39 +02:00
|
|
|
}
|
2020-11-20 05:36:18 +01:00
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SuppressApplicationTitle())
|
2021-03-08 16:23:50 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SuppressApplicationTitle().Value())
|
2021-03-08 16:23:50 +01:00
|
|
|
{
|
|
|
|
ss << fmt::format(L"suppress application title, ");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"use application title, ");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
auto s = ss.str();
|
|
|
|
if (s.empty())
|
|
|
|
{
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ", "
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 2) };
|
|
|
|
}
|
|
|
|
|
2021-02-20 00:51:30 +01:00
|
|
|
winrt::hstring NewTerminalArgs::ToCommandline() const
|
|
|
|
{
|
|
|
|
std::wstringstream ss;
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Profile().empty())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"--profile \"{}\" ", Profile());
|
2021-02-20 00:51:30 +01:00
|
|
|
}
|
|
|
|
// The caller is always expected to provide the evaluated profile in the
|
|
|
|
// NewTerminalArgs, not the index
|
|
|
|
//
|
2021-05-20 20:44:04 +02:00
|
|
|
// else if (ProfileIndex())
|
2021-02-20 00:51:30 +01:00
|
|
|
// {
|
2021-05-20 20:44:04 +02:00
|
|
|
// ss << fmt::format(L"profile index: {}, ", ProfileIndex().Value());
|
2021-02-20 00:51:30 +01:00
|
|
|
// }
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!StartingDirectory().empty())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-08-03 20:16:07 +02:00
|
|
|
// If the directory ends in a '\', we need to add another one on so that the enclosing quote added
|
|
|
|
// afterwards isn't escaped
|
|
|
|
const auto trailingBackslashEscape = StartingDirectory().back() == L'\\' ? L"\\" : L"";
|
|
|
|
ss << fmt::format(L"--startingDirectory \"{}{}\" ", StartingDirectory(), trailingBackslashEscape);
|
2021-02-20 00:51:30 +01:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!TabTitle().empty())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"--title \"{}\" ", TabTitle());
|
2021-02-20 00:51:30 +01:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TabColor())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
const til::color tabColor{ TabColor().Value() };
|
2021-02-20 00:51:30 +01:00
|
|
|
ss << fmt::format(L"--tabColor \"{}\" ", tabColor.ToHexString(true));
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SuppressApplicationTitle())
|
2021-03-08 16:23:50 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SuppressApplicationTitle().Value())
|
2021-03-08 16:23:50 +01:00
|
|
|
{
|
|
|
|
ss << fmt::format(L"--suppressApplicationTitle ");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << fmt::format(L"--useApplicationTitle ");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!ColorScheme().empty())
|
2021-03-29 22:04:39 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"--colorScheme \"{}\" ", ColorScheme());
|
2021-03-29 22:04:39 +02:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Commandline().empty())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << fmt::format(L"-- \"{}\" ", Commandline());
|
2021-02-20 00:51:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
auto s = ss.str();
|
|
|
|
if (s.empty())
|
|
|
|
{
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last " "
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 1) };
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring CopyTextArgs::GenerateName() const
|
|
|
|
{
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
std::wstringstream ss;
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SingleLine())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
ss << RS_(L"CopyTextAsSingleLineCommandKey").c_str();
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << RS_(L"CopyTextCommandKey").c_str();
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (CopyFormatting())
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
{
|
|
|
|
ss << L", copyFormatting: ";
|
2021-05-20 20:44:04 +02:00
|
|
|
if (CopyFormatting().Value() == CopyFormat::All)
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
{
|
|
|
|
ss << L"all, ";
|
|
|
|
}
|
2021-05-20 20:44:04 +02:00
|
|
|
else if (CopyFormatting().Value() == static_cast<CopyFormat>(0))
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
{
|
|
|
|
ss << L"none, ";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (WI_IsFlagSet(CopyFormatting().Value(), CopyFormat::HTML))
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
{
|
|
|
|
ss << L"html, ";
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (WI_IsFlagSet(CopyFormatting().Value(), CopyFormat::RTF))
|
Add copyFormatting keybinding arg and array support (#6004)
Adds array support for the existing `copyFormatting` global setting.
This allows users to define which formats they would specifically like
to be copied.
A boolean value is still accepted and is translated to the following:
- `false` --> `"none"` or `[]`
- `true` --> `"all"` or `["html", "rtf"]`
This also adds `copyFormatting` as a keybinding arg for `copy`. As with
the global setting, a boolean value and array value is accepted.
CopyFormat is a WinRT enum where each accepted format is a flag.
Currently accepted formats include `html`, and `rtf`. A boolean value is
accepted and converted. `true` is a conjunction of all the formats.
`false` only includes plain text.
For the global setting, `null` is not accepted. We already have a
default value from before so no worries there.
For the keybinding arg, `null` (the default value) means that we just do
what the global arg says to do. Overall, the `copyFormatting` keybinding
arg is an override of the global setting **when using that keybinding**.
References #5212 - Spec for formatted copying
References #2690 - disable html copy
Validated behavior with every combination of values below:
- `copyFormatting` global: { `true`, `false`, `[]`, `["html"]` }
- `copyFormatting` copy arg:
{ `null`, `true`, `false`, `[]`, `[, "html"]`}
Closes #4191
Closes #5262
2020-08-15 03:02:24 +02:00
|
|
|
{
|
|
|
|
ss << L"rtf, ";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ","
|
|
|
|
auto result = ss.str();
|
|
|
|
return winrt::hstring{ result.substr(0, result.size() - 2) };
|
|
|
|
}
|
|
|
|
|
|
|
|
return winrt::hstring{ ss.str() };
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring NewTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring newTerminalArgsStr;
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TerminalArgs())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
newTerminalArgsStr = TerminalArgs().GenerateName();
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (newTerminalArgsStr.empty())
|
|
|
|
{
|
|
|
|
return RS_(L"NewTabCommandKey");
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, {}", RS_(L"NewTabCommandKey"), newTerminalArgsStr)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
Move Pane to Tab (GH7075) (#10780)
<!-- 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 move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
winrt::hstring MovePaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, tab index:{}", RS_(L"MovePaneCommandKey"), TabIndex())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring SwitchToTabArgs::GenerateName() const
|
|
|
|
{
|
2021-07-22 15:48:36 +02:00
|
|
|
if (TabIndex() == UINT32_MAX)
|
|
|
|
{
|
|
|
|
return RS_(L"SwitchToLastTabCommandKey");
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
return winrt::hstring{
|
2021-05-20 20:44:04 +02:00
|
|
|
fmt::format(L"{}, index:{}", RS_(L"SwitchToTabCommandKey"), TabIndex())
|
2020-06-26 22:38:02 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring ResizePaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (ResizeDirection())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Left:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionLeft");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Right:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionRight");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Up:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionUp");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case ResizeDirection::Down:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionDown");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ResizePaneWithArgCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring MoveFocusArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (FocusDirection())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Left:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionLeft");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Right:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionRight");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Up:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionUp");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Down:
|
2020-06-26 22:38:02 +02:00
|
|
|
directionString = RS_(L"DirectionDown");
|
|
|
|
break;
|
Support for navigating panes by MRU (#8183)
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
2020-12-11 19:36:05 +01:00
|
|
|
case FocusDirection::Previous:
|
|
|
|
return RS_(L"MoveFocusToLastUsedPane");
|
2021-08-17 00:33:23 +02:00
|
|
|
case FocusDirection::NextInOrder:
|
|
|
|
return RS_(L"MoveFocusNextInOrder");
|
|
|
|
case FocusDirection::PreviousInOrder:
|
|
|
|
return RS_(L"MoveFocusPreviousInOrder");
|
2021-08-26 19:58:56 +02:00
|
|
|
case FocusDirection::First:
|
|
|
|
return RS_(L"MoveFocusFirstPane");
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
2021-08-26 19:58:56 +02:00
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"MoveFocusWithArgCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
Move Pane to Tab (GH7075) (#10780)
<!-- 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 move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
winrt::hstring SwapPaneArgs::GenerateName() const
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#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.
2021-07-22 14:53:03 +02:00
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
|
|
|
switch (Direction())
|
|
|
|
{
|
|
|
|
case FocusDirection::Left:
|
|
|
|
directionString = RS_(L"DirectionLeft");
|
|
|
|
break;
|
|
|
|
case FocusDirection::Right:
|
|
|
|
directionString = RS_(L"DirectionRight");
|
|
|
|
break;
|
|
|
|
case FocusDirection::Up:
|
|
|
|
directionString = RS_(L"DirectionUp");
|
|
|
|
break;
|
|
|
|
case FocusDirection::Down:
|
|
|
|
directionString = RS_(L"DirectionDown");
|
|
|
|
break;
|
|
|
|
case FocusDirection::Previous:
|
Move Pane to Tab (GH7075) (#10780)
<!-- 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 move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
return RS_(L"SwapPaneToLastUsedPane");
|
2021-08-17 00:33:23 +02:00
|
|
|
case FocusDirection::NextInOrder:
|
|
|
|
return RS_(L"SwapPaneNextInOrder");
|
|
|
|
case FocusDirection::PreviousInOrder:
|
|
|
|
return RS_(L"SwapPanePreviousInOrder");
|
2021-08-26 19:58:56 +02:00
|
|
|
case FocusDirection::First:
|
|
|
|
return RS_(L"SwapPaneFirstPane");
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#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.
2021-07-22 14:53:03 +02:00
|
|
|
}
|
2021-08-26 19:58:56 +02:00
|
|
|
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#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.
2021-07-22 14:53:03 +02:00
|
|
|
return winrt::hstring{
|
Move Pane to Tab (GH7075) (#10780)
<!-- 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 move a pane to another tab. If the tab index is greater than the number of current tabs a new tab will be created with the pane as its root. Similarly, if the last pane on a tab is moved to another tab, the original tab will be closed.
This is largely complete, but I know that I'm messing around with things that I am unfamiliar with, and would like to avoid footguns where possible.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4587
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #7075
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [x] 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
Things done:
- Moving a pane to a new tab appears to work. Moving a pane to an existing tab mostly works. Moving a pane back to its original tab appears to work.
- Set up {Attach,Detach}Pane methods to add or remove a pane from a pane. Detach is slightly different than Close in that we want to persist the tree structure and terminal controls.
- Add `Detached` event on a pane that can be subscribed to to remove other event handlers if desired.
- Added simple WalkTree abstraction for one-off recursion use cases that calls a provided function on each pane in order (and optionally terminates early).
- Fixed an in-prod bug with closing panes. Specifically, if you have a tree (1; 2 3) and close the 1 pane, then 3 will lose its borders because of these lines clearing the border on both children https://github.com/microsoft/terminal/blob/main/src/cascadia/TerminalApp/Pane.cpp#L1197-L1201 .
To do:
- Right now I have `TerminalTab` as a friend class of `Pane` so I can access some extra properties in my `WalkTree` callbacks, but there is probably a better choice for the abstraction boundary.
Next Steps:
- In a future PR Drag & Drop handlers could be added that utilize the Attach/Detach infrastructure to provide a better UI.
- Similarly once this is working, it should be possible to convert an entire tab into a pane on an existing tab (Tab::DetachRoot on original tab followed by Tab::AttachPane on the target tab).
- Its been 10 years, I just really want to use concepts already.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual testing by creating pane(s), and moving them between tabs and creating new tabs and destroying tabs by moving the last remaining pane.
2021-08-12 18:41:17 +02:00
|
|
|
fmt::format(std::wstring_view(RS_(L"SwapPaneWithArgCommandKey")),
|
Preliminary work to add Swap Panes functionality (GH Issues 1000, 4922) (#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.
2021-07-22 14:53:03 +02:00
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring AdjustFontSizeArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// If the amount is just 1 (or -1), we'll just return "Increase font
|
|
|
|
// size" (or "Decrease font size"). If the amount delta has a greater
|
|
|
|
// absolute value, we'll include it like"
|
|
|
|
// * Decrease font size, amount: {delta}"
|
2021-05-20 20:44:04 +02:00
|
|
|
if (Delta() < 0)
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
return Delta() == -1 ? RS_(L"DecreaseFontSizeCommandKey") :
|
|
|
|
winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"DecreaseFontSizeWithAmountCommandKey")),
|
|
|
|
-Delta())
|
|
|
|
};
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
return Delta() == 1 ? RS_(L"IncreaseFontSizeCommandKey") :
|
|
|
|
winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"IncreaseFontSizeWithAmountCommandKey")),
|
|
|
|
Delta())
|
|
|
|
};
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-12 15:46:53 +02:00
|
|
|
winrt::hstring SendInputArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// The string will be similar to the following:
|
|
|
|
// * "Send Input: ...input..."
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
auto escapedInput = til::visualize_control_codes(Input());
|
2020-08-12 15:46:53 +02:00
|
|
|
auto name = fmt::format(std::wstring_view(RS_(L"SendInputCommandKey")), escapedInput);
|
|
|
|
return winrt::hstring{ name };
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring SplitPaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// The string will be similar to the following:
|
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543)
## Summary of the Pull Request
Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one.
This also adds the param to the `split-pane` subcommand.
### Examples
| commandline | result |
| -- | -- |
| `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) |
| `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) |
| `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) |
## PR Checklist
* [x] Closes #6298
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#208
## Detailed Description of the Pull Request / Additional comments
I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version.
## Validation Steps Performed
Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
|
|
|
// * "Duplicate pane[, split: <direction>][, size: <size>%][, new terminal arguments...]"
|
|
|
|
// * "Split pane[, split: <direction>][, size: <size>%][, new terminal arguments...]"
|
2020-06-26 22:38:02 +02:00
|
|
|
//
|
|
|
|
// Direction will only be added to the string if the split direction is
|
|
|
|
// not "auto".
|
|
|
|
// If this is a "duplicate pane" action, then the new terminal arguments
|
|
|
|
// will be omitted (as they're unused)
|
|
|
|
|
|
|
|
std::wstringstream ss;
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SplitMode() == SplitType::Duplicate)
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
ss << std::wstring_view(RS_(L"DuplicatePaneCommandKey"));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ss << std::wstring_view(RS_(L"SplitPaneCommandKey"));
|
|
|
|
}
|
|
|
|
ss << L", ";
|
|
|
|
|
|
|
|
// This text is intentionally _not_ localized, to attempt to mirror the
|
|
|
|
// exact syntax that the property would have in JSON.
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (SplitStyle())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
case SplitState::Vertical:
|
|
|
|
ss << L"split: vertical, ";
|
|
|
|
break;
|
|
|
|
case SplitState::Horizontal:
|
|
|
|
ss << L"split: horizontal, ";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SplitSize() != .5f)
|
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543)
## Summary of the Pull Request
Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one.
This also adds the param to the `split-pane` subcommand.
### Examples
| commandline | result |
| -- | -- |
| `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) |
| `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) |
| `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) |
## PR Checklist
* [x] Closes #6298
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#208
## Detailed Description of the Pull Request / Additional comments
I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version.
## Validation Steps Performed
Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << L"size: " << (SplitSize() * 100) << L"%, ";
|
Add `size` param to `splitPane` action, `split-pane` subcommand (#8543)
## Summary of the Pull Request
Adds a `size` parameter to `splitPane`. This takes a `float`, and specifies the portion of the parent pane that should be used to create the new one.
This also adds the param to the `split-pane` subcommand.
### Examples
| commandline | result |
| -- | -- |
| `wt ; sp -s .25` | ![image](https://user-images.githubusercontent.com/18356694/101784317-fb595680-3ac0-11eb-8248-782dc61957cf.png) |
| `wt ; sp -s .8` | ![image](https://user-images.githubusercontent.com/18356694/101784442-20e66000-3ac1-11eb-8f9b-fb45a73c9334.png) |
| `wt ; sp -s .8 ; sp -H -s .3` | ![image](https://user-images.githubusercontent.com/18356694/101784552-470c0000-3ac1-11eb-9deb-df37aaa36f01.png) |
## PR Checklist
* [x] Closes #6298
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#208
## Detailed Description of the Pull Request / Additional comments
I went with `size`, `--size,-s` rather than `percent`, because the arg is the (0,1) version of the size, not the (0%,100%) version.
## Validation Steps Performed
Added actions, played with the commandline, ran tests
2020-12-18 04:51:53 +01:00
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring newTerminalArgsStr;
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TerminalArgs())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
newTerminalArgsStr = TerminalArgs().GenerateName();
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
if (SplitMode() != SplitType::Duplicate && !newTerminalArgsStr.empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
ss << newTerminalArgsStr.c_str();
|
|
|
|
ss << L", ";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Chop off the last ", "
|
|
|
|
auto s = ss.str();
|
|
|
|
return winrt::hstring{ s.substr(0, s.size() - 2) };
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring OpenSettingsArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (Target())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
case SettingsTarget::DefaultsFile:
|
|
|
|
return RS_(L"OpenDefaultSettingsCommandKey");
|
|
|
|
case SettingsTarget::AllFiles:
|
|
|
|
return RS_(L"OpenBothSettingsFilesCommandKey");
|
2021-02-24 01:14:13 +01:00
|
|
|
case SettingsTarget::SettingsFile:
|
|
|
|
return RS_(L"OpenSettingsCommandKey");
|
2021-01-04 23:14:51 +01:00
|
|
|
case SettingsTarget::SettingsUI:
|
2020-06-26 22:38:02 +02:00
|
|
|
default:
|
2021-02-24 01:14:13 +01:00
|
|
|
return RS_(L"OpenSettingsUICommandKey");
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-10 18:21:56 +02:00
|
|
|
winrt::hstring SetColorSchemeArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Set color scheme to "{_SchemeName}""
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!SchemeName().empty())
|
2020-08-10 18:21:56 +02:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"SetColorSchemeCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
SchemeName().c_str())
|
2020-08-10 18:21:56 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
2020-06-26 22:38:02 +02:00
|
|
|
winrt::hstring SetTabColorArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Set tab color to #RRGGBB"
|
|
|
|
// "Reset tab color"
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TabColor())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
til::color tabColor{ TabColor().Value() };
|
2020-06-26 22:38:02 +02:00
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"SetTabColorCommandKey")),
|
2020-11-20 05:36:18 +01:00
|
|
|
tabColor.ToHexString(true))
|
2020-06-26 22:38:02 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
return RS_(L"ResetTabColorCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring RenameTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Rename tab to \"{_Title}\""
|
|
|
|
// "Reset tab title"
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Title().empty())
|
2020-06-26 22:38:02 +02:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"RenameTabCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
Title().c_str())
|
2020-06-26 22:38:02 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ResetTabNameCommandKey");
|
|
|
|
}
|
|
|
|
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
winrt::hstring ExecuteCommandlineArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Run commandline "{_Commandline}" in this window"
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Commandline().empty())
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ExecuteCommandlineCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
Commandline().c_str())
|
Add support for running a `wt` commandline in the curent window WITH A KEYBINDING (#6537)
## Summary of the Pull Request
Adds a execute commandline action (`wt`), which lets a user bind a key to a specific `wt` commandline. This commandline will get parsed and run _in the current window_.
## References
* Related to #4472
* Related to #5400 - I need this for the commandline mode of the Command Palette
* Related to #5970
## PR Checklist
* [x] Closes oh, there's not actually an issue for this.
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - yes it does
## Detailed Description of the Pull Request / Additional comments
One important part of this change concerns how panes are initialized at runtime. We've had some persistent trouble with initializing multiple panes, because they rely on knowing how big they'll actually be, to be able to determine if they can split again.
We previously worked around this by ignoring the size check when we were in "startup", processing an initial commandline. This PR however requires us to be able to know the initial size of a pane at runtime, but before the parents have necessarily been added to the tree, or had their renderer's set up.
This led to the development of `Pane::PreCalculateCanSplit`, which is very highly similar to `Pane::PreCalculateAutoSplit`. This method attempts to figure out how big a pane _will_ take, before the parent has necessarily laid out.
This also involves a small change to `TermControl`, because if its renderer hasn't been set up yet, it'll always think the font is `{0, fontHeight}`, which will let the Terminal keep splitting in the x direction. This change also makes the TermControl set up a renderer to get the real font size when it hasn't yet been initialized.
## Validation Steps Performed
This was what the json blob I was using for testing evolved into
```json
{
"command": {
"action":"wt",
"commandline": "new-tab cmd.exe /k #work 15 ; split-pane cmd.exe /k #work 15 ; split-pane cmd.exe /k media-commandline ; new-tab powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu\" ; new-tab -p \"haunter.gif\" ; focus-tab -t 0",
},
"keys": ["ctrl+shift+n"]
}
```
I also added some tests.
# TODO
* [x] Creating a `{ "command": "wt" }` action without a commandline will spawn a new `wt.exe` process?
- Probably should just do nothing for the empty string
2020-07-17 23:05:29 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
|
|
|
|
2020-08-06 23:47:50 +02:00
|
|
|
winrt::hstring CloseOtherTabsArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (Index())
|
2020-08-25 21:25:25 +02:00
|
|
|
{
|
|
|
|
// "Close tabs other than index {0}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"CloseOtherTabsCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
Index().Value())
|
2020-08-25 21:25:25 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"CloseOtherTabsDefaultCommandKey");
|
2020-08-06 23:47:50 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring CloseTabsAfterArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (Index())
|
2020-08-25 21:25:25 +02:00
|
|
|
{
|
|
|
|
// "Close tabs after index {0}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"CloseTabsAfterCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
Index().Value())
|
2020-08-25 21:25:25 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"CloseTabsAfterDefaultCommandKey");
|
2020-08-06 23:47:50 +02:00
|
|
|
}
|
2020-10-27 02:19:52 +01:00
|
|
|
|
2021-06-25 21:22:52 +02:00
|
|
|
winrt::hstring CloseTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
if (Index())
|
|
|
|
{
|
|
|
|
// "Close tab at index {0}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"CloseTabAtIndexCommandKey")),
|
|
|
|
Index().Value())
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"CloseTabCommandKey");
|
|
|
|
}
|
|
|
|
|
2020-10-27 02:19:52 +01:00
|
|
|
winrt::hstring ScrollUpArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (RowsToScroll())
|
2020-10-27 02:19:52 +01:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ScrollUpSeveralRowsCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
RowsToScroll().Value())
|
2020-10-27 02:19:52 +01:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ScrollUpCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring ScrollDownArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (RowsToScroll())
|
2020-10-27 02:19:52 +01:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"ScrollDownSeveralRowsCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
RowsToScroll().Value())
|
2020-10-27 02:19:52 +01:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ScrollDownCommandKey");
|
|
|
|
}
|
2020-11-25 23:09:27 +01:00
|
|
|
|
|
|
|
winrt::hstring MoveTabArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring directionString;
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (Direction())
|
2020-11-25 23:09:27 +01:00
|
|
|
{
|
|
|
|
case MoveTabDirection::Forward:
|
|
|
|
directionString = RS_(L"MoveTabDirectionForward");
|
|
|
|
break;
|
|
|
|
case MoveTabDirection::Backward:
|
|
|
|
directionString = RS_(L"MoveTabDirectionBackward");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"MoveTabCommandKey")),
|
|
|
|
directionString)
|
|
|
|
};
|
|
|
|
}
|
2020-12-03 17:15:31 +01:00
|
|
|
|
|
|
|
winrt::hstring ToggleCommandPaletteArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (LaunchMode() == CommandPaletteLaunchMode::CommandLine)
|
2020-12-03 17:15:31 +01:00
|
|
|
{
|
|
|
|
return RS_(L"ToggleCommandPaletteCommandLineModeCommandKey");
|
|
|
|
}
|
|
|
|
return RS_(L"ToggleCommandPaletteCommandKey");
|
|
|
|
}
|
Add `findNext`, `findPrev` actions (#8917)
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results.
Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!
If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.
## Validation Steps Performed
I've played with it all day and it seems _crisp_.
Closes #7695
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
|
|
|
|
|
|
|
winrt::hstring FindMatchArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
switch (Direction())
|
Add `findNext`, `findPrev` actions (#8917)
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.
This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results.
Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!
If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.
## Validation Steps Performed
I've played with it all day and it seems _crisp_.
Closes #7695
Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
2021-02-18 20:21:35 +01:00
|
|
|
{
|
|
|
|
case FindMatchDirection::Next:
|
|
|
|
return winrt::hstring{ RS_(L"FindNextCommandKey") };
|
|
|
|
case FindMatchDirection::Previous:
|
|
|
|
return winrt::hstring{ RS_(L"FindPrevCommandKey") };
|
|
|
|
}
|
|
|
|
return L"";
|
|
|
|
}
|
2021-02-20 00:51:30 +01:00
|
|
|
|
|
|
|
winrt::hstring NewWindowArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
winrt::hstring newTerminalArgsStr;
|
2021-05-20 20:44:04 +02:00
|
|
|
if (TerminalArgs())
|
2021-02-20 00:51:30 +01:00
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
newTerminalArgsStr = TerminalArgs().GenerateName();
|
2021-02-20 00:51:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (newTerminalArgsStr.empty())
|
|
|
|
{
|
|
|
|
return RS_(L"NewWindowCommandKey");
|
|
|
|
}
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(L"{}, {}", RS_(L"NewWindowCommandKey"), newTerminalArgsStr)
|
|
|
|
};
|
|
|
|
}
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
|
|
|
|
winrt::hstring PrevTabArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!SwitcherMode())
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
{
|
|
|
|
return RS_(L"PrevTabCommandKey");
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
const auto mode = SwitcherMode().Value() == TabSwitcherMode::MostRecentlyUsed ? L"most recently used" : L"in order";
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
return winrt::hstring(fmt::format(L"{}, {}", RS_(L"PrevTabCommandKey"), mode));
|
|
|
|
}
|
|
|
|
|
|
|
|
winrt::hstring NextTabArgs::GenerateName() const
|
|
|
|
{
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!SwitcherMode())
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
{
|
|
|
|
return RS_(L"NextTabCommandKey");
|
|
|
|
}
|
|
|
|
|
2021-05-20 20:44:04 +02:00
|
|
|
const auto mode = SwitcherMode().Value() == TabSwitcherMode::MostRecentlyUsed ? L"most recently used" : L"in order";
|
Allow overriding tab switcher mode on command level (#9507)
## Summary of the Pull Request
Currently, when the MRU is enabled we lose the keybinding allowing us to
go forward/backward (aka right/left in LTR) in the tab view.
To fix that, this PR introduces "tabSwitcherMode" optional parameter to
the prevTab / nextTab commands.
If it is not provided the global setting will be used.
So if you want to go to adjacent tabs, even if MRU is enabled on the
system level you can use:
```
{ "command": { "action": "prevTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "inOrder" }, "keys": "ctrl+f2"}
```
or even
```
{"command": { "action": "prevTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f1"}
{ "command": { "action": "nextTab", "tabSwitcherMode": "disabled" }, "keys": "ctrl+f2"}
```
if you don't want tab switcher to show up
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/9330
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - not yet. Waiting for approval.
* [x] Schema updated.
* [ ] I've discussed this with core contributors already.
2021-03-23 23:00:07 +01:00
|
|
|
return winrt::hstring(fmt::format(L"{}, {}", RS_(L"NextTabCommandKey"), mode));
|
|
|
|
}
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
|
|
|
|
winrt::hstring RenameWindowArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Rename window to \"{_Name}\""
|
|
|
|
// "Clear window name"
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Name().empty())
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
{
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"RenameWindowCommandKey")),
|
2021-05-20 20:44:04 +02:00
|
|
|
Name().c_str())
|
Add support for renaming windows (#9662)
## Summary of the Pull Request
This PR adds support for renaming windows.
![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)
It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
`TextBox`. When the user hits Ok, it'll request a rename for the provided
value. This lets the user pick a new name for the window at runtime.
In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!
## References
* Builds on the toasts from #9523
* #5000 - process model megathread
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.
> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!
## Validation Steps Performed
I've been playing with
```json
{ "keys": "f1", "command": "identifyWindow" },
{ "keys": "f2", "command": "identifyWindows" },
{ "keys": "f3", "command": "openWindowRenamer" },
{ "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
{ "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```
and they seem to work as expected
2021-04-02 18:00:04 +02:00
|
|
|
};
|
|
|
|
}
|
|
|
|
return RS_(L"ResetWindowNameCommandKey");
|
|
|
|
}
|
2021-04-29 00:13:28 +02:00
|
|
|
|
|
|
|
winrt::hstring GlobalSummonArgs::GenerateName() const
|
|
|
|
{
|
2021-07-13 00:31:17 +02:00
|
|
|
// GH#10210 - Is this action literally the same thing as the `quakeMode`
|
|
|
|
// action? That has a special name.
|
|
|
|
static const auto quakeModeArgs{ std::get<0>(GlobalSummonArgs::QuakeModeFromJson(Json::Value::null)) };
|
|
|
|
if (quakeModeArgs.Equals(*this))
|
|
|
|
{
|
|
|
|
return RS_(L"QuakeModeCommandKey");
|
|
|
|
}
|
|
|
|
|
2021-04-29 00:13:28 +02:00
|
|
|
std::wstringstream ss;
|
|
|
|
ss << std::wstring_view(RS_(L"GlobalSummonCommandKey"));
|
|
|
|
|
|
|
|
// "Summon the Terminal window"
|
|
|
|
// "Summon the Terminal window, name:\"{_Name}\""
|
2021-05-20 20:44:04 +02:00
|
|
|
if (!Name().empty())
|
2021-04-29 00:13:28 +02:00
|
|
|
{
|
|
|
|
ss << L", name: ";
|
2021-05-20 20:44:04 +02:00
|
|
|
ss << std::wstring_view(Name());
|
2021-04-29 00:13:28 +02:00
|
|
|
}
|
|
|
|
return winrt::hstring{ ss.str() };
|
|
|
|
}
|
2021-05-21 23:55:57 +02:00
|
|
|
|
|
|
|
winrt::hstring FocusPaneArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Focus pane {Id}"
|
|
|
|
return winrt::hstring{
|
|
|
|
fmt::format(std::wstring_view(RS_(L"FocusPaneCommandKey")),
|
|
|
|
Id())
|
|
|
|
};
|
|
|
|
}
|
2021-09-02 16:59:42 +02:00
|
|
|
winrt::hstring ClearBufferArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
// "Clear Buffer"
|
|
|
|
// "Clear Viewport"
|
|
|
|
// "Clear Scrollback"
|
|
|
|
switch (Clear())
|
|
|
|
{
|
|
|
|
case Control::ClearBufferType::All:
|
|
|
|
return RS_(L"ClearAllCommandKey");
|
|
|
|
case Control::ClearBufferType::Screen:
|
|
|
|
return RS_(L"ClearViewportCommandKey");
|
|
|
|
case Control::ClearBufferType::Scrollback:
|
|
|
|
return RS_(L"ClearScrollbackCommandKey");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return the empty string - the Clear() should be one of these values
|
|
|
|
return winrt::hstring{ L"" };
|
|
|
|
}
|
Add action to run multiple actions. (#11045)
<!-- 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 a new action that can contain multiple other actions.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #3992
* [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
* [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
Creates a shortcut action that allows a list of actions to be specified as arguments. Steals a bunch of the serialization code from my other pr. Overall, because I had the serialization code written already, this was remarkably easy.
I can't think of any combined action to be added to the defaults, so I think this is just a thing for the documentation unless someone else has a good example. I know there are lot of times when the recommended workaround is "make an action with commandline wt.exe ..." and this could be a good replacement for that, but that is all personalized.
I didn't add this to the command line parsing, since the command line is already a way to run multiple actions.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Created a new command, confirmed that "Move right->down" showed up in the command palette, and that running it did the correct behavior (moving right one pane, then down one pane).
```
{
"command": {
"action": "multipleActions",
"name": "Move right->down",
"actions": [
{"action": "moveFocus", "direction": "right" },
{"action": "moveFocus", "direction": "down" },
]
}
}
```
2021-08-31 21:35:51 +02:00
|
|
|
|
|
|
|
winrt::hstring MultipleActionsArgs::GenerateName() const
|
|
|
|
{
|
|
|
|
return L"";
|
|
|
|
}
|
2020-06-26 22:38:02 +02:00
|
|
|
}
|