03ebe514e9
## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.**  This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
31 lines
1 KiB
Plaintext
31 lines
1 KiB
Plaintext
// Copyright (c) Microsoft Corporation.
|
|
// Licensed under the MIT license.
|
|
|
|
import "Peasant.idl";
|
|
|
|
namespace Microsoft.Terminal.Remoting
|
|
{
|
|
|
|
[default_interface] runtimeclass FindTargetWindowArgs {
|
|
CommandlineArgs Args { get; };
|
|
Int32 ResultTargetWindow;
|
|
}
|
|
|
|
[default_interface] runtimeclass ProposeCommandlineResult {
|
|
Windows.Foundation.IReference<UInt64> Id { get; };
|
|
// TODO:projects/5 - also return the name here, if the name was set on the commandline
|
|
Boolean ShouldCreateWindow { get; }; // If you name this `CreateWindow`, the compiler will explode
|
|
}
|
|
|
|
[default_interface] runtimeclass Monarch {
|
|
Monarch();
|
|
|
|
UInt64 GetPID();
|
|
UInt64 AddPeasant(IPeasant peasant);
|
|
ProposeCommandlineResult ProposeCommandline(CommandlineArgs args);
|
|
void HandleActivatePeasant(WindowActivatedArgs args);
|
|
|
|
event Windows.Foundation.TypedEventHandler<Object, FindTargetWindowArgs> FindTargetWindowRequested;
|
|
};
|
|
}
|