2019-05-03 00:29:04 +02:00
|
|
|
// Copyright (c) Microsoft Corporation.
|
|
|
|
// Licensed under the MIT license.
|
|
|
|
|
|
|
|
import "IKeyBindings.idl";
|
2021-04-09 00:46:16 +02:00
|
|
|
import "IControlAppearance.idl";
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
namespace Microsoft.Terminal.Control
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
|
|
|
enum ScrollbarState
|
|
|
|
{
|
|
|
|
Visible = 0,
|
|
|
|
Hidden
|
|
|
|
};
|
|
|
|
|
2020-02-25 23:19:57 +01:00
|
|
|
enum TextAntialiasingMode
|
|
|
|
{
|
|
|
|
Grayscale = 0,
|
|
|
|
Cleartype,
|
|
|
|
Aliased
|
|
|
|
};
|
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
// 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.
|
2021-04-09 00:46:16 +02:00
|
|
|
interface IControlSettings requires Microsoft.Terminal.Core.ICoreSettings, Microsoft.Terminal.Control.IControlAppearance
|
2019-05-03 00:29:04 +02:00
|
|
|
{
|
2020-02-28 01:37:56 +01:00
|
|
|
String ProfileName;
|
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
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;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
String FontFace;
|
|
|
|
Int32 FontSize;
|
2020-05-20 22:17:17 +02:00
|
|
|
Windows.UI.Text.FontWeight FontWeight;
|
2019-05-03 00:29:04 +02:00
|
|
|
String Padding;
|
2021-07-23 01:15:44 +02:00
|
|
|
Windows.Foundation.Collections.IMap<String, UInt32> FontFeatures;
|
|
|
|
Windows.Foundation.Collections.IMap<String, Single> FontAxes;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2021-03-17 21:47:24 +01:00
|
|
|
Microsoft.Terminal.Control.IKeyBindings KeyBindings;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2020-03-25 22:09:49 +01:00
|
|
|
Boolean CopyOnSelect;
|
2021-02-09 23:18:20 +01:00
|
|
|
Boolean FocusFollowMouse;
|
2020-03-25 22:09:49 +01:00
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
String Commandline;
|
|
|
|
String StartingDirectory;
|
|
|
|
String EnvironmentVariables;
|
|
|
|
|
2020-06-09 00:31:28 +02:00
|
|
|
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;
|
2019-05-03 00:29:04 +02:00
|
|
|
};
|
|
|
|
}
|