2021-04-09 00:46:16 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
namespace Microsoft.Terminal.Core
|
|
|
|
{
|
|
|
|
enum CursorStyle
|
|
|
|
{
|
|
|
|
Vintage,
|
|
|
|
Bar,
|
|
|
|
Underscore,
|
|
|
|
DoubleUnderscore,
|
|
|
|
FilledBox,
|
|
|
|
EmptyBox
|
|
|
|
};
|
|
|
|
|
|
|
|
// TerminalCore declares its own Color struct to avoid depending
|
|
|
|
// on Windows.UI.Color and to avoid passing around unclothed uint32s.
|
|
|
|
// It is supported by til::color for conversions in and out of WinRT land.
|
|
|
|
struct Color
|
|
|
|
{
|
|
|
|
UInt8 R;
|
|
|
|
UInt8 G;
|
|
|
|
UInt8 B;
|
|
|
|
UInt8 A;
|
|
|
|
};
|
|
|
|
|
Only access ControlInteractivity through the projection (#10051)
## Summary of the Pull Request
This forces the `TermControl` to only use `ControlCore` and `ControlInteractivity` via their WinRT projections. We want this, because WinRT projections can be used across process boundaries. In the future, `ControlCore` and `ControlInteractivity` are going to be living in a different process entirely from `TermControl`. By enforcing this boundary now, we can make sure that they will work seamlessly in the future.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760270
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Most all this was just converting pure c++ types to winrt types when possible. I've added a couple helper projections with `til` converters, which made most of this really easy.
The "`MouseButtonState` needs to be composed of `Int32`s instead of `bool`s" is MENTAL. I have no idea why this is, but when I had the control OOP in the sample, that would crash when trying to de-marshal the bools. BODGY.
The biggest changes are in the way the UIA stuff is hooked up. The UiaEngine needs to be attached directly to the `Renderer`, and it can't be easily projected, so it needs to live next to the `ControlCore`. But the `TermControlAutomationPeer` needed the `UiaEngine` to help implement some interfaces.
Now, there's a new layer we've introduced. `InteractivityAutomationPeer` does the `ITextProvider`, `IControlAccessibilityInfo` and the `IUiaEventDispatcher` thing. `TermControlAutomationPeer` now has a
`InteractivityAutomationPeer` stashed inside itself, so that it can ask the interactivity layer to do the real work. We still need the `TermControlAutomationPeer` though, to be able to attach to the real UI tree.
## Validation Steps Performed
The terminal behaves basically the same as before.
Most importantly, I whipped out Accessibility Insights, and the Terminal looks the same as before.
2021-07-19 18:59:30 +02:00
|
|
|
// TerminalCore declares its own Color struct to avoid depending on
|
|
|
|
// Windows.UI. Windows.Foundation.Point also exists, but it's composed of
|
|
|
|
// floating-point coordinates, when we almost always need integer coordinates.
|
|
|
|
// It is supported by til::point for conversions in and out of WinRT land.
|
|
|
|
struct Point
|
|
|
|
{
|
|
|
|
Int32 X;
|
|
|
|
Int32 Y;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Same thing here, but with padding. Can't use Windows.UI.Thickness, so
|
|
|
|
// we'll declare our own.
|
|
|
|
struct Padding {
|
|
|
|
Double Left;
|
|
|
|
Double Top;
|
|
|
|
Double Right;
|
|
|
|
Double Bottom;
|
|
|
|
};
|
|
|
|
|
|
|
|
// This is a projection of Microsoft::Terminal::Core::ControlKeyStates,
|
|
|
|
// for conversions in and out of WinRT land.
|
|
|
|
struct ControlKeyStates
|
|
|
|
{
|
|
|
|
UInt32 Value;
|
|
|
|
};
|
|
|
|
|
2021-04-09 00:46:16 +02:00
|
|
|
declare
|
|
|
|
{
|
|
|
|
// Forward declare this parameterized specialization so that it lives
|
|
|
|
// in TerminalCore instead of being flung to the winds of all IDL dependents.
|
|
|
|
interface Windows.Foundation.IReference<Microsoft.Terminal.Core.Color>;
|
Only access ControlInteractivity through the projection (#10051)
## Summary of the Pull Request
This forces the `TermControl` to only use `ControlCore` and `ControlInteractivity` via their WinRT projections. We want this, because WinRT projections can be used across process boundaries. In the future, `ControlCore` and `ControlInteractivity` are going to be living in a different process entirely from `TermControl`. By enforcing this boundary now, we can make sure that they will work seamlessly in the future.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760270
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Most all this was just converting pure c++ types to winrt types when possible. I've added a couple helper projections with `til` converters, which made most of this really easy.
The "`MouseButtonState` needs to be composed of `Int32`s instead of `bool`s" is MENTAL. I have no idea why this is, but when I had the control OOP in the sample, that would crash when trying to de-marshal the bools. BODGY.
The biggest changes are in the way the UIA stuff is hooked up. The UiaEngine needs to be attached directly to the `Renderer`, and it can't be easily projected, so it needs to live next to the `ControlCore`. But the `TermControlAutomationPeer` needed the `UiaEngine` to help implement some interfaces.
Now, there's a new layer we've introduced. `InteractivityAutomationPeer` does the `ITextProvider`, `IControlAccessibilityInfo` and the `IUiaEventDispatcher` thing. `TermControlAutomationPeer` now has a
`InteractivityAutomationPeer` stashed inside itself, so that it can ask the interactivity layer to do the real work. We still need the `TermControlAutomationPeer` though, to be able to attach to the real UI tree.
## Validation Steps Performed
The terminal behaves basically the same as before.
Most importantly, I whipped out Accessibility Insights, and the Terminal looks the same as before.
2021-07-19 18:59:30 +02:00
|
|
|
interface Windows.Foundation.IReference<Microsoft.Terminal.Core.Point>;
|
2021-04-09 00:46:16 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
interface ICoreAppearance
|
|
|
|
{
|
|
|
|
Microsoft.Terminal.Core.Color DefaultForeground;
|
|
|
|
Microsoft.Terminal.Core.Color DefaultBackground;
|
|
|
|
Microsoft.Terminal.Core.Color GetColorTableEntry(Int32 index);
|
|
|
|
Microsoft.Terminal.Core.Color CursorColor;
|
|
|
|
CursorStyle CursorShape;
|
|
|
|
UInt32 CursorHeight;
|
Add an ENUM setting for disabling rendering "intense" text as bold (#10759)
## Summary of the Pull Request
This adds a new setting `intenseTextStyle`. It's a per-appearance, control setting, defaulting to `"all"`.
* When set to `"all"` or `["bold", "bright"]`, then we'll render text as both **bold** and bright (1.10 behavior)
* When set to `"bold"`, `["bold"]`, we'll render text formatted with `^[[1m` as **bold**, but not bright
* When set to `"bright"`, `["bright"]`, we'll render text formatted with `^[[1m` as bright, but not bold. This is the pre 1.10 behavior
* When set to `"none"`, we won't do anything special for it at all.
## references
* I last did this in #10648. This time it's an enum, so we can add bright in the future. It's got positive wording this time.
* ~We will want to add `"bright"` as a value in the future, to disable the auto intense->bright conversion.~ I just did that now.
* #5682 is related
## PR Checklist
* [x] Closes #10576
* [x] I seriously don't think we have an issue for "disable intense is bright", but I'm not crazy, people wanted that, right? https://github.com/microsoft/terminal/issues/2916#issuecomment-544880423 was the closest
* [x] I work here
* [x] Tests added/passed
* [x] https://github.com/MicrosoftDocs/terminal/pull/381
## Validation Steps Performed
<!-- ![image](https://user-images.githubusercontent.com/18356694/125480327-07f6b711-6bca-4c1b-9a76-75fc978c702d.png) -->
![image](https://user-images.githubusercontent.com/18356694/128929228-504933ee-cf50-43a2-9982-55110ba39191.png)
Yea that works. Printed some bold text, toggled it on, the text was no longer bold. hooray.
### EDIT, 10 Aug
```json
"intenseTextStyle": "none",
"intenseTextStyle": "bold",
"intenseTextStyle": "bright",
"intenseTextStyle": "all",
"intenseTextStyle": ["bold", "bright"],
```
all work now. Repro script:
```sh
printf "\e[1m[bold]\e[m[normal]\e[34m[blue]\e[1m[bold blue]\e[m\n"
```
2021-08-16 15:45:56 +02:00
|
|
|
Boolean IntenseIsBright;
|
2021-10-08 00:43:17 +02:00
|
|
|
Boolean AdjustIndistinguishableColors;
|
2021-04-09 00:46:16 +02:00
|
|
|
};
|
|
|
|
}
|