mirror of
https://github.com/microsoft/terminal.git
synced 2025-12-19 18:11:39 -05:00
774f74258f
This upgrades to [check-spelling v0.0.24]. A number of GitHub APIs are being turned off shortly, so we need to upgrade or various uncertain outcomes will occur. There are some minor bugs that I'm aware of and which I've fixed since this release (including a couple I discovered while preparing this PR). There's a new accessibility forbidden pattern: #### Should be `cannot` (or `can't`) See https://www.grammarly.com/blog/cannot-or-can-not/ > Don't use `can not` when you mean `cannot`. The only time you're likely to see `can not` written as separate words is when the word `can` happens to precede some other phrase that happens to start with `not`. > `Can't` is a contraction of `cannot`, and it's best suited for informal writing. > In formal writing and where contractions are frowned upon, use `cannot`. > It is possible to write `can not`, but you generally find it only as part of some other construction, such as `not only . . . but also.` - if you encounter such a case, add a pattern for that case to patterns.txt. ``` \b[Cc]an not\b ``` [check-spelling v0.0.24]: https://github.com/check-spelling/check-spelling/releases/tag/v0.0.24 Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
116 lines
4.9 KiB
Markdown
116 lines
4.9 KiB
Markdown
---
|
|
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` itself 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<GUID>`
|
|
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 foresee 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 its 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
|
|
|
|
decide to host a WebView in a pane, then it surely could impact these measures.
|
|
I don't believe this will have a noticeable impact _on its own_. Should the user
|
|
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 if the 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
|