A pane doesn't necessarily need to host a terminal.

[zadjii-msft]

A pane doesn't necessarily need to host a terminal. It could potentially host another UIElement. One could imagine enabling a user to quickly open up a Browser pane to search for a particular string without needing to leave the terminal.

notes:

• dev/migrie/f/non-terminal-panes was the original prototype This prototype built a media pane for the Terminal. An example screenshot: I can't find the original gif, cause that was from 2019. The demo deck is in a recording linked to a mail from jeffbog "RE: DEP Hackathon Share-Out", 8/7/2019
• dev/migrie/fhl/adaptive-card-extension had a draft of this in Oct 2021
• dev/migrie/fhl/non-terminal-panes-2023 an attempted start circa May 2023. Didn't have more than a few hours for it though.
  • dev/migrie/fhl/scratchpad-pane for the branch with a test pane in it.
    • dev/migrie/f/sui-panes
      • dev/migrie/fhl-fall-2023/oceans
        • A comment from leonard: you can just render an HWND to a Composition surface, and then insert a comp surface into the xaml tree. So look at that next hackathon
      • dev/migrie/fhl/tasks-pane, somewhere in the neighborhood of #13445

[mdtauk]

This issue is related I believe #644

[DHowett-MSFT]

From @sharpninja in #4719,

Description of the new feature/enhancement

I know this may seem way out there, but hear me out.

Windows Terminal is about tools. A single window open that has our command line tools in one place. There are many things that go along with that that are better when provided as a GUI, such as Settings for tools. In addition, other things, such as package managers, greatly benefit from having a GUI to observe listings of packages and their details. These GUIs are related to our open command prompts and it would be great of they could be shown in the same Window.

Proposed technical implementation details (optional)

A Visual Studio template would be created to build a Windows Terminal Plugin. It would have metadata that would specify commands that could be typed in the terminal that would be processed by Windows Terminal upon hitting Enter on the keyboard (and only when invoked from the keyboard) that if found would pass the entire command line to the Plugin. Example:

!packages nuget list Microsoft.Extensions.*

This would invoke a plugin named "packages" which would in turn parse the command line and determine it needed to get a list of packages from nuget that match Microsoft.Extensions.* and display the results in the GUI. It would only interact with the Profile it was invoked from.

Other examples are accelerators for Dotnet core such that a Plugin could be open with a set of buttons for common actions/macros that the user may need. This would be great for system admins who might administer 50 machines and run the same powershell commands on each of them. Currently she would have to add aliases to profiles on potentially each machine. No bueno! This way she sets up some macros in a GUI, enables the plugin for that Profile and then can invoke her predetermined commands.

Another really useful plugin would be a Text Editor that could be used for profiles and scripts. The data would be piped to/from the Console for reading and saving. Another example is a file manager that could be used to move data between profiles over encrypted pipes.

Performing actions against a profile would always be done through the Plugin system. Communication would be STDIN/STDOUT to the console. A GUI could take the whole window or split the window vertically or horizontally and be resizable. Plugins would be exposed through a Store and could be imported via nuget packages.

[zadjii-msft]

c66a56656 might be a commit that enables this, accidentally while working on something else.

[zadjii-msft]

<showerthought>

what if we just had the Terminal create an HWND in the space of that pane, and let a OOP extension just get that HWND and put whatever it wants into it? Terminal would be responsible for resizing the HWND, hiding it, whatever. It'd be a child HWND of the Terminal, so it'd necessarily be tied to our window. But then a 3p app could just put a Xaml Island in it's own child HWND, in its own process?

Terminal 
└── Our Xaml Island
    └── HwndPane HWND
        └── Extension HWND
            └── Extension Xaml Island