From 038d6e5fafaee4cbb62f7e6f86c2ed35889d27a8 Mon Sep 17 00:00:00 2001 From: Mike Griese Date: Fri, 5 Jun 2020 13:14:01 -0500 Subject: [PATCH] First draft of a spec for panes with non-terminal content (#1080) Co-authored-by: Michael Niksa putting outdated draft spec into drafts folder and closing PR. CI has no function on docs. --- doc/{cascadia => specs}/Keybindings-spec.md | 0 .../TerminalSettings-spec.md | 0 doc/specs/drafts/#997 Non-Terminal-Panes.md | 115 ++++++++++++++++++ 3 files changed, 115 insertions(+) rename doc/{cascadia => specs}/Keybindings-spec.md (100%) rename doc/{cascadia => specs}/TerminalSettings-spec.md (100%) create mode 100644 doc/specs/drafts/#997 Non-Terminal-Panes.md diff --git a/doc/cascadia/Keybindings-spec.md b/doc/specs/Keybindings-spec.md similarity index 100% rename from doc/cascadia/Keybindings-spec.md rename to doc/specs/Keybindings-spec.md diff --git a/doc/cascadia/TerminalSettings-spec.md b/doc/specs/TerminalSettings-spec.md similarity index 100% rename from doc/cascadia/TerminalSettings-spec.md rename to doc/specs/TerminalSettings-spec.md diff --git a/doc/specs/drafts/#997 Non-Terminal-Panes.md b/doc/specs/drafts/#997 Non-Terminal-Panes.md new file mode 100644 index 000000000..35e16ff57 --- /dev/null +++ b/doc/specs/drafts/#997 Non-Terminal-Panes.md @@ -0,0 +1,115 @@ +--- +author: Mike Griese @zadjii-msft +created on: 2019-05-31 +last updated: 2019-05-31 +issue id: #997 +--- + +# Non-Terminal Panes + +## Abstract + +This spec hopes to cover the work necessary to enable panes to host non-terminal +content. It'll describe changes to the `Pane` class to support hosting arbitrary +controls in addition to terminals. + +## Inspiration + +The primary driver for this change is to enable testing of the pane code. If a +`Pane` can host an arbitrary class, then a use case for that would be the +hosting of a non-xaml test class that acts like a control. This test class could +be have its state queried, to make sure that the panes are properly delivering +focus to the correct pane content. + +Additionally, non-terminal panes could be used to host a variety of other +content, such as browser panes, sticky notes, text editor scratch-pads, etc. +Some discussion of these ideas are in #644. + +## Solution Design + +We'll change the TermControl class to derive from the +`Windows.UI.Xaml.Controls.Control` runtime class. +* We may need to override its `FocusState` and `Focus` methods, and implement + them by plumbing them straight through to the fake Control the `TermControl` + hosts. +* Otherwise, it might be possible that we could just remove that fake control + entirely. +* We'll remove the `GetControl` method from the `TermControl`, as the + `TermControl` itslef will now be used as the control. + +We'll change the Pane class to accept a `Windows.UI.Xaml.Controls.Control` +instead of a `TermControl`. + +We'll additionally change the `Pane` constructor to accept an `optional` +as opposed to needing a GUID. For constructing panes with Terminals, we should +pass a GUID corresponding to that settings profile. For panes that aren't +hosting terminals however, we should pass `nullopt` as the GUID. For panes that +are leaf nodes (panes which are hosting a control, not another pair of panes), +if the pane has a GUID, we can assume that the control is a TermControl. + +When we want to host other types of content, we'll simply pass any other control +to the Pane, and it'll render it just as it would the `TermControl`. + +## UI/UX Design + +Instead of a pane hosting a terminal, it could host _any arbitrary control_. The +control would still be subject to the sizing provided to it by the `Pane`, but +it could host any arbitrary content. + +## Capabilities + +### Security + +I don't forsee this implementation by itself raising security concerns. This +feature is mostly concerned with adding support for arbitrary controls, not +actually implementing some arbitrary controls. + +### Reliability + +With more possible controls in a pane than just a terminal, it's possible that +crashes in those controls could impact the entire Terminal app's reliability. +This would largely be out of our control, as we only author the TermControl. + +We may want to consider hosting each pane in it's own process, similar to how +moder browsers will host each tab in its own process, to help isolate tabs. This +is a bigger discussion than the feature at hand, however. + +### Performance, Power, and Efficiency + +I don't believe this will have a noticable impact _on its own_. Should the user +decide to host a WebView in a pane, then it surely could impact these measuress. +However, I leave that discussion to the implementation of the actual alternative +pane content itself. + +### Accessibility + +When implementing the accessibility tree for Panes, we'll need to make sure that +for panes with arbitrary content, we properly activate their accessibility, +should the control provide some sort of accessibility pattern. + +## Potential Issues + +* [ ] It's entirely possible that panes with non-terminal content will not be + able to activate keybindings from the terminal application. For example, what + if the hosted control wants to use Ctrl+T for its own shortcut? The current + keybindings model has the `TermControl` call into the App layer to see if a + keystroke should be handled by the app first. We may want to make sure that + for non-terminal controls, we add a event handler to try and have the + `AppKeyBindings` handle the keypress ifthe control doesn't. This won't solve + the case where the control wants to use a keybinding that is mapped by the + Terminal App. In that case, non-terminal controls will actually behave + differently from the `TermControl`. The `TermControl` will give the app the + first chance to handle a keybinding, while for other controls, the app will + give the control the first chance to handle the keypress. This may be mildly + confusing to end users. + +## Future considerations + +I expect this to be a major part of our (eventual) extensibility model. By +allowing arbitrary controls to be hosted in a Tab/Pane, this will allow +extension authors to embed their own UI experiences alongside the terminal. +See #555 for more discussion on the extensibility/plugin subject. + +## Resources + +N/A