terminal/src/cascadia/TerminalControl/IControlSettings.idl

57 lines
1.6 KiB
Plaintext
Raw Normal View History

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.
import "IKeyBindings.idl";
import "IControlAppearance.idl";
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
namespace Microsoft.Terminal.Control
{
enum ScrollbarState
{
Visible = 0,
Hidden
};
enum TextAntialiasingMode
{
Grayscale = 0,
Cleartype,
Aliased
};
// Class Description:
// TerminalSettings encapsulates all settings that control the
// TermControl's behavior. In these settings there is both the entirety
// of the Core ITerminalSettings interface, and any additional settings
// for specifically the control.
interface IControlSettings requires Microsoft.Terminal.Core.ICoreSettings, Microsoft.Terminal.Control.IControlAppearance
{
Define Automation Properties for TermControl (#4732) Defines the following automation properties for a Terminal Control: - [**Orientation**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getorientationcore): - The orientation of the control - None --> Vertical - [**Name**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getnamecore): - The name as used by assistive technology and other Microsoft UI Automation clients. Generally presented by automation clients as the primary way to identify an element (along with the control type) - "" --> <profile name> - [**HelpText**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.gethelptextcore): - The help text. Generally presented by automation clients if requested by the user. This would be something that you would normally expect to appear from tooltips. - "" --> <tab title> - [**LiveSetting**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getlivesettingcore): - reports the live setting notification behavior. A representation of how assertive this control should be when content changes. - none --> Polite ## Detailed Description of the Pull Request / Additional comments ProfileName had to be added to the TerminalSettings (IControlSettings) to pass that information along to the automation peer. In the rare event that somebody purposefully decided to make their ProfileName empty, we fallback to the tab title. ## Validation Steps Performed Verified using Accessibility Insights and inspect.exe This is are some examples of the information a general user can expect to receive about a Terminal Control. - Type: Terminal Control - Name: Command Prompt - Help Text (if requested): Command Prompt - ping bing.com - Type: Terminal Control - Name: Ubuntu - Help Text (if requested): cazamor@PC-cazamor:/mnt/c/Users/cazamor$ Note, it is generally read by an automation client as follows: "<type>, <name>" References #2099 - Automation Properties for TerminalControl, Search Box References #2142 - Localization Closes #2142
2020-02-28 01:37:56 +01:00
String ProfileName;
Boolean UseAcrylic;
A better fix for #tab-titles-are-too-long (#2373) ### User Stories: 1. A user wants to be able to use the executable path as their starting title - Does anyone want this? 2. A user wants to be able to set a custom starting title, but have that title be overridable 3. A user wants to be able to set an overridable starting title, different from the profile name - Presumably someone will want this 4. A user totally wants to ignore the VT title and use something else - This will make more sense in the post [#1320] "Support runtime variables in the custom user title" settings ### Solutions: 1. `name`, `startingTitle`, `tabTitle` * a. `name` is only ever used as the profile name. * b. If `startingTitle` isn't set, then the executable path is used * c. If `startingTitle` is set, it's used as the initial title * d. If `tabTitle` is set, it overrides the title from the terminal * e. Current users of `tabTitle` need to manually update to the new behavior. 2. `name` as starting title, `tabTitle` as a different starting title * a. `name` is used as the starting title and the profile name in the dropdown * b. If `tabTitle` is set, we'll use that as the overridable starting title instead. * c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320] * d. Current users of `tabTitle` automatically get the new (different!) behavior. * e. User Story 1 is impossible - Does anyone want the behavior _ever_? Perhaps making that scenario impossible is good? 3. `name` unchanged, `tabTitle` as the starting title * a. `name` is only ever used as the profile name. * b. If `tabTitle` is set, we'll use that as the overridable starting title. * c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320] * d. Current users of `tabTitle` automatically get the new (different!) behavior. 4. `name` as starting title, `tabTitle` as different starting title, `suppressApplicationTitle` Boolean to force it to override * a. `name`, `tabTitle` work as in Solution 2. * b. When someone wants to be able to statically totally override that title (story 4), they can use `suppressApplicationTitle` * c. `suppressApplicationTitle` name is WIP * d. We'll add `suppressApplicationTitle` when someone complains * e. If you really want story 1, use `tabTitle: c:\path\to\foo.exe` and `suppressApplicationTitle`. [#1320]: https://github.com/microsoft/terminal/issues/1320 We've decided to pursue path 4.
2019-08-15 01:16:38 +02:00
ScrollbarState ScrollState;
String FontFace;
Int32 FontSize;
Add font weight options (#6048) ## Summary of the Pull Request Adds the ability to specify the font weight in the profiles, right next to the size and the font face. ## PR Checklist * [x] Closes #1751 * [x] I work here. * [x] Tested manually, see below. * [x] Added documentation to the schema * [x] Requires docs.microsoft.com update, filed as https://github.com/MicrosoftDocs/terminal/issues/26 * [x] I'm a core contributor. ## Detailed Description of the Pull Request / Additional comments - Weights can be specified according to the OpenType specification values. We accept either the friendly name or the numerical value that applies to each weight. - Weights are carried through per-profile and sent into the renderer. - Weights are carried through to the TSF/IME overlay. - The names are restricted to the set seen at https://docs.microsoft.com/en-us/uwp/api/windows.ui.text.fontweights. - There are alternate names at https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ne-dwrite-dwrite_font_weight for the same values (ultra-black is just an alias for extra-black at 950). ## Validation Steps Performed - Cascadia Code normal ![image](https://user-images.githubusercontent.com/18221333/82480181-46117380-9a88-11ea-9436-a5fe4ccd4350.png) - Cascadia Code bold ![image](https://user-images.githubusercontent.com/18221333/82480202-4f9adb80-9a88-11ea-9e27-a113b41387f5.png) - Segoe UI Semilight ![image](https://user-images.githubusercontent.com/18221333/82480306-73f6b800-9a88-11ea-93f7-d773ab7ccce8.png) - Segoe UI Black ![image](https://user-images.githubusercontent.com/18221333/82480401-9688d100-9a88-11ea-957c-0c8e03a8cc29.png) - Segoe UI 900 (value for Black) ![image](https://user-images.githubusercontent.com/18221333/82480774-26c71600-9a89-11ea-8cf6-aaeab1fd0747.png)
2020-05-20 22:17:17 +02:00
Windows.UI.Text.FontWeight FontWeight;
String Padding;
Windows.Foundation.Collections.IMap<String, UInt32> FontFeatures;
Windows.Foundation.Collections.IMap<String, Single> FontAxes;
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
Microsoft.Terminal.Control.IKeyBindings KeyBindings;
2020-03-25 22:09:49 +01:00
Boolean CopyOnSelect;
Boolean FocusFollowMouse;
2020-03-25 22:09:49 +01:00
String Commandline;
String StartingDirectory;
String EnvironmentVariables;
TextAntialiasingMode AntialiasingMode;
Implement user-specified pixel shaders, redux (#8565) Co-authored-by: mrange <marten_range@hotmail.com> I loved the pixel shaders in #7058, but that PR needed a bit of polish to be ready for ingestion. This PR is almost _exactly_ that PR, with some small changes. * It adds a new pre-profile setting `"experimental.pixelShaderPath"`, which lets the user set a pixel shader to use with the Terminal. - CHANGED FROM #7058: It does _not_ add any built-in shaders. - CHANGED FROM #7058: it will _override_ `experimental.retroTerminalEffect` * It adds a bunch of sample shaders in `samples/shaders`. Included: - A NOP shader as a base to build from. - An "invert" shader that inverts the colors, as a simple example - An "grayscale" shader that converts all colors to grayscale, as a simple example - An "raster bars" shader that draws some colored bars on the screen with a drop shadow, as a more involved example - The original retro terminal effects, as a more involved example - It also includes a broken shader, as an example of what heppens when the shader fails to compile - CHANGED FROM #7058: It does _not_ add the "retroII" shader we were all worried about. * When a shader fails to be found or fails to compile, we'll display an error dialog to the user with a relevant error message. - CHANGED FROM #7058: Originally, #7058 would display "error bars" on the screen. I've removed that, and had the Terminal disable the shader entirely then. * Renames the `toggleRetroEffect` action to `toggleShaderEffect`. (`toggleRetroEffect` is now an alias to `toggleShaderEffect`). This action will turn the shader OR the retro effects on/off. `toggleShaderEffect` works the way you'd expect it to, but the mental math on _how_ is a little weird. The logic is basically: ``` useShader = shaderEffectsEnabled ? (pixelShaderProvided ? pixelShader : (retroEffectEnabled ? retroEffect : null ) ) : null ``` and `toggleShaderEffect` toggles `shaderEffectsEnabled`. * If you've got both a shader and retro enabled, `toggleShaderEffect` will toggle between the shader on/off. * If you've got a shader and retro disabled, `toggleShaderEffect` will toggle between the shader on/off. References #6191 References #7058 Closes #7013 Closes #3930 "Add setting to retro terminal shader to control blur radius, color" Closes #3929 "Add setting to retro terminal shader to enable drawing scanlines" - At this point, just roll your own version of the shader.
2020-12-15 21:40:22 +01:00
// Experimental Settings
Add renderer settings to mitigate blurry text for some graphics devices ## Summary of the Pull Request Adds user settings to adjust rendering behavior to mitigate blurry text on some devices. ## References - #778 introduced this, almost certainly. ## PR Checklist * [x] Closes #5759, mostly * [x] I work here. * [ ] We need community verification that this will help. * [x] Updated schema and schema doc. * [x] Am core contributor. Discussed in Monday sync meeting and w/ @DHowett-MSFT. ## Detailed Description of the Pull Request / Additional comments When we switched from full-screen repaints to incremental rendering, it seems like we exposed a situation where some display drivers and hardware combinations do not handle scroll and/or dirty regions (from `IDXGISwapChain::Present1`) without blurring the data from the previous frame. As we're really close to ship, I'm offering two options to let people in this situation escape it on their own. We hope in the future to figure out what's actually going on here and mitigate it further in software, but until then, these escape hatches are available. 1. `experimental.rendering.forceFullRepaint` - This one restores the pre-778 behavior to the Terminal. On every single frame paint, we'll invalidate the entire screen and repaint it. 2. `experimental.rendering.software` - This one uses the software WARP renderer instead of using the hardware and display driver directly. The theory is that this will sidestep any driver bugs or hardware variations. One, the other, or both of these may be field-applied by users who are experiencing this behavior. Reverting #778 completely would also resolve this, but it would give back our largest performance win in the whole Terminal project. We don't believe that's acceptable when seemingly a majority of the users are experiencing the performance benefit with no detriment to graphical display. ## Validation Steps Performed - [x] Flipped them on and verified with the debugger that they are being applied to the rendering pipeline - [ ] Gave a private copy to community members in #5759 and had them try whether one, the other, or both resolved their issue.
2020-05-11 23:54:03 +02:00
Boolean ForceFullRepaintRendering;
Boolean SoftwareRendering;
};
}