As we start to work on implementing Action IDs, the spec written a few
years ago needs some updates. This PR makes those updates for the
current implementation plan.
References #6899
Right now, the localization submission pipeline runs every night and
sends our localizable resources over to Touchdown. Later, release builds
pick up the localizations directly from Touchdown, move them into place,
and consume them.
This allowed us to avoid having localized content in the repository, but
it came with too many downsides:
- Users could not contribute additional localizations very easily
- We use the same release pipeline and Touchdown configuration for every
branch, so strings needed to either slightly match or _entirely match_
across an entire set of active release branches
- Building from day to day can pull in different strings, making the
product not reproduceable
- Calling TDBuild during release builds requires network access from the
build machine (so does restoring NuGet packages, but that's neither
here nor there)
- Local developers and users could not test out other languages
This pull request moves all localization processing into the nightly
build phase and introduces support for checking loc in and submitting a
pull request. The pull request will not be created anew if one already
exists which has not been merged.
Anything we needed to do on release is now done overnight. This includes
moving loc files into the right places and merging the Cascadia
resources with the Context Menu resources (so that we can work around a
relatively lower amount of translations being chosen for the app versus
the context menu; see #12491 for more info.)
There are some smaller downsides to this approach and its
implementation:
- The first commit is going to be huge
- Right now, it only manages a single branch and uses a force push; if a
PR is not reviewed timely, it will be force-pushed and you cannot see
the day-to-day changes in the strings. Hopefully there won't be any.
I've taken great care to ensure that repeated runs of this new pipeline
will not result in unnecessary whitespace changes. This required
changing how we merge ContextMenu.resw into CascadiaPackage to always
use the .NET XmlWriter with specific flags.
NOTE that this does not allow users to _contribute_ translation fixes
for the 10 languages which we are importing. We will still need to pull
changes out of those files and submit them as bugs to the localization
team separately, and hope they come back around in another nightly
build. However, there is no reason users cannot contribute
_non-Touchdown_ languages.
We don't need to use `stringstream` to generate a ten-character string,
and we for _sure_ don't need to use the locale-aware ctype functions
after we just wrote a comment saying "XOrg colors are always Latin-1"
| Size Diff | Object | Library |
| --------- | -------------- | -------- |
| -11.8 KB | colorTable.obj | ConTypes |
I realize I might be one of the few developers that care about custom
shader support in terminal but I thought it's worth proposing it and see
what you think.
This is to support custom shaders with custom textures.
I was thinking of exposing the background image to the shader but that
felt complicated after looking into it.
I have tested exploratively. I think the texture loader is possible to
unit test so that is a possible improvement.
The error reporting (as with other custom pixel shader code) is not very
good. That is also an area that I could improve upon.
I do think the risk of adding this is rather low as the new code is only
executed when experimental.pixelShaderImagePath is set.
### Details
Only added to the Atlas engine.
Instead I load the texture using WIC into a shader resource view. When
binding shader resources I test for presence of custom texture and bind
it to register t1.
The image loading code was found in [the D3D Texture documentation].
It's a mouthful but seems rather robust.
Tested setting: "experimental.pixelShaderImagePath"
1. Tested not specifying it.
2. Tested setting it.
3. Tested changing it (the changes are picked up)
4. Tested invalid path
5. Tested a custom shader that made use of the custom texture.
[the D3D Texture documentation]: https://learn.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-resources-textures-how-to
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
"ConptyConnection::CreateSettings()" was modified to include some extra
parameters related to the environment variable changes. This just
updates the call in Scratch.sln so that it builds and deploys properly.
When using the legacy console APIs, it's possible to write arbitrary
codepoints into the buffer. If any of those codepoints are in the C0 or
C1 range, and the buffer contents are forwarded over conpty, they can
end up mistakenly interpreted as controls by the connected terminal.
This PR fixes that issue by converting any C0 and C1 codepoints in the
buffer into printable glyphs before forwarding them over conpty. I've
used the C0 glyphs from the DOS 437 codepage and just a `?` for the C1
codepoints, since that's what you would typically have seen in the v1
console with a raster font.
Although this doesn't address the main problem in #16410, it should at
least fix the rendering issues they're seeing when running their app in
Windows Terminal.
I've confirmed that the test case in #4363 now looks the same in Windows
Terminal as it does in conhost, and I've tested the Windows version of
the terminal game [Gorched], and confirmed that it now works correctly
in Window Terminal.
[Gorched]: https://github.com/zladovan/gorchedCloses#4363Closes#6265
Welp, would you look at that? We never actually supported "canary"
feature settings. Canary's been defaulting to the "Dev" config since
inception.
There's a couple things that are supposed to only be on in Dev and not
Canary. They clearly haven't mattered, but better safe than sorry!
This PR adds support for the `OSC 21` sequence used on DEC terminals to
set the window title. It's just an alias of the `OSC 2` title sequence
used by XTerm.
This PR also corrects the handling of blank title sequences, which are
supposed to reset the title to its default value, but were previously
ignored.
## Detailed Description of the Pull Request / Additional comments
To handle the blank title parsing correctly, I had to make some changes
to the state machine. Previously it would not have dispatched an `OSC`
sequence unless it received a semicolon following the `OSC` number, but
when there's a blank string, that semicolon should not be required.
I also took this opportunity to simplify the `OSC` parsing in the state
machine, and eliminate the `_GetOscTitle` method which no longer served
any purpose.
## Validation Steps Performed
I've manually confirmed that the title sequences are now working as
expected, and added some state machine unit tests covering the blank
value handling for these sequences.
I also had to update one of the existing state machine tests to account
for the changes I made to allow the semicolon to be omitted.
Closes#16783Closes#16784
This pull request introduces the module Microsoft.Terminal.UI.dll, and
moves into it the following things:
- Any `IDirectKeyListener`
- All XAML converter helpers from around the project
- ... including `IconPathConverter` from TerminalSettingsModel
- ... but not `EmptyStringVisibilityConverter`, which has died
It also adds a XAML Markup Extension named `mtu:ResourceString`, which
will allow us to refer to string resources directly from XAML. It will
allow us to remove all of the places in the code where we manually set
resources on XAML controls.
---------
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Make sure the delete button's `Tag` updates when the selected
axis/feature changes, so that the correct key value gets propagated when
the delete button is clicked.
Refs #16678#16104
## Validation Steps Performed
1. Add a new feature/axis
2. Change the key
3. Click the delete button
4. Delete button works
Aside from overall simplifying `CharToColumnMapper` this fixes 2 bugs:
* The backward search loop may have iterated 1 column too far,
because it didn't stop at `*current <= *target`, but rather at
`*(current - 1) <= *target`. This issue was only apparent when
surrogate pairs were being used in a row.
* When the target offset is that of a trailing surrogate pair
the forward search loop may have iterated 1 column too far.
It's somewhat unlikely for this to happen since this code is
only used through ICU, but you never know.
This is a continuation of PR #16775.
This is just a minor cleanup I did as a drive-by while working on
customized font fallback. The benefit of this change is that it's
a tiny bit less expensive, but also that it's a lot easier to read.
The split into "get index" and "get string by index" helps us to
more easily handle both, missing locales and locale fallback.
The code that ties everything together then ends up being just 7 lines.
## Summary of the Pull Request
Allow editing of font features and axes in the SUI to get the UI closer
towards JSON parity
The allowed font axes are obtained directly from the currently selected
font, and their display names are presented to the user in the user's
current locale (if it exists). Otherwise, we just display the axis tag
to the user.
## References and Relevant Issues
#10000
## Validation Steps Performed
- [x] Font Axes can be added/changed/removed from the Settings UI
## PR Checklist
- [ ] Closes #xxx
- [ ] Tests added/passed
- [ ] Documentation updated
- If checked, please file a pull request on [our docs
repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
- [ ] Schema updated (if necessary)
This pull request removes the need for the SettingsModel tests to run in
a UAP harness and puts them into the standard CI rotation.
This required some changes to `Run-Tests.ps1` to ensure that the right
`te.exe` is selected for each test harness. It's a bit annoying, but for
things that depend on a `resources.pri`, that file must be in the same
directory as the EXE that is hosting the test. Not the DLL, mind you,
the EXE. In our case, that's `TE.ProcessHost.exe`
The bulk of the change is honestly namespace tidying.
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Shaded glyphs (U+2591..3, etc.) all have one problem in common:
The cell size may not be evenly divisible by the pixel/dot size in
the glyph. This either results in blurring, or in moiré-like patterns
at the edges of the cells with its neighbors, because they happen to
start with a pattern that overlaps with the end of the previous cell.
This PR solves the issue by moving the pixel/dot pattern generation
into the shader. That way the pixel/dot location can be made dependent
on the viewport-position of the actual underlying pixels, which avoids
repeating patterns between cells.
The PR contains some additional modifications, all of which either
extend or improve the existing debug facilities in AtlasEngine.
Suppressing whitespaces changes makes the diff way smaller.
`wstring_case_insensitive_compare` is not a great name for what it
does as it's incorrect to use for regular (human readable) strings.
This PR thus renames it to `env_key_sorter`.
`compare_string_ordinal` was renamed to `compare_ordinal_insensitive`
to make sure callers know that the comparison is insensitive
(this may otherwise be incorrect in certain contexts after all).
The return value was changed to match `memcmp` so that the API
is detached from its underlying implementation (= NLS).
`compare_linguistic_insensitive` and `contains_linguistic_insensitive`
were added to sort and filter human-readable strings respectively.
`prefix_split` was extended to allow for needles that are just a
single character. This significantly improves the generated assembly
and is also usually what someone would want to actually use.
I've left the string-as-needle variant in just in case.
This PR is prep-work for #2664
## Summary of the Pull Request
URL detection was broken again in #15858. When the regex matched, we
calculate the column(cell) by its offset, we use forward or backward
iteration of the column to find the correct column that displays the
glyphs of `_chars[offset]`.
abf5d9423a/src/buffer/out/Row.cpp (L95-L104)
However, when calculating the `currentOffset` we forget that MSB of
`_charOffsets[col]` could be `1`, or col is pointing to another glyph in
preceding column.
abf5d9423a/src/buffer/out/Row.hpp (L223-L226)
Up until now, we have treated inbox, fragment and user color schemes the
same: we load them all into one big map and when we save the settings
file we write them *all* out. It's been a big annoyance pretty much
forever.
In addition to cluttering the user's settings file, it prevents us from
making changes to the stock color schemes (like to change the cursor
color, or to adjust the colors in Tango Dark, or what have you) because
they're already copied in full in the user settings. It also means that
we need some special UI affordances for color schemes that you are
allowed to view but not to delete or rename.
We also have a funny hardcoded list of color scheme names and we use
that to determine whether they're "inbox" for UI purposes.
Because of all that, we are hesitant to add *more* color schemes to the
default set.
This pull request resolves all of those issues at once.
It:
- Adds an "origin" to color schemes indicating where they're from
(Inbox, Fragment, User, ...)
- Replaces the Edit UI with a much simpler version that pretty much only
has a "duplicate this color scheme to start editing it" button
- Deletes color schemes that we consider to be equivalent to inbox ones;
this allows us to finally disentangle the user's preferences from the
terminal's.
- Migrates all user settings that referred to schemes they may have
modified (even implicitly!) to their modified versions.
The equivalence check intentionally leaves out the cursor and selection
colors, so that we have the freedom to change them in the future.
The Origin is part of a new interface, `ISettingsModelObject`, which we
can use in the future for things like Themes and Actions.
I thought, "what if I could just have a script make all the releases,
tags and names and upload all the assets to the right place?"
So, here's that script.
Basically, title. If you null out the icon, we'll automatically try to
use the `commandline` as an icon (because we can now). We'll even be
smart about it - `cmd.exe /k echo wassup` will still just use the ico of
`cmd.exe`.
This doesn't work for `ubuntu.exe` (et. al), because that commandline is
technically a reparse point, that doesn't actually have an icon
associated with it.
Closes#705
`"none"` becomes our sentinel value for "no icon".
This will also use the same `NormalizeCommandLine` we use for
commandline matching for finding the full path to the exe.
Surprisingly easier than I thought this would be. ActionMap already
supports layering (from defaults.json), so this basically re-uses a lot
of that for fun and profit.
The trickiest bits:
* In `SettingsLoader::_parseFragment`, I'm constructing a fake, empty
JSON object, and taking _only_ the actions out from the fragment, and
stuffing them into this temp json. Then, I parse that as a globals
object, and set _that_ as the parent to the user settings file. That
results in _only_ the actions from the fragment being parsed before the
user's actions.
* In that same method, I'm also explicitly preventing the ActionMap (et
al.) from parsing `keys` from these actions. We don't want fragments to
be able to say "ctrl+f is clear buffer" or something like that. This
required a bit of annoying plumbing.
Closes#16063
Tests added.
Docs need to be updated.
This includes a fix for the hang on shutdown due to the folder change
reader.
WIL now validates format strings in `LOG...` macros (yay!) and so we
needed to fix some of our `LOG` macros.
Closes#16456
(cherry picked from commit ce30e7c89c)
Service-Card-Id: 91923199
Service-Version: 1.19
This changeset makes 3 improvements:
* Dotted lines now use a 2:1 ratio between gaps and dots (from 1:1).
This makes the dots a lot easier to spot at small font sizes.
* Dashed lines use a 1:2 ratio and a cells-size independent stride.
By being cell-size independent it works more consistently with a
wider variety of fonts with weird cell aspect ratios.
* Curly lines are now cell-size independent as well and have a
height that equals the double-underline size.
This ensures that the curve isn't cut off anymore and just like
with dashed lines, that it works under weird aspect ratios.
Closes#16712
## Validation Steps Performed
This was tested using RenderingTests using Cascadia Mono, Consolas,
Courier New, Lucida Console and MS Gothic.
(cherry picked from commit 9c8058c326)
Service-Card-Id: 91922825
Service-Version: 1.19
This adds support for drawing our own box drawing, block element,
and basic Powerline (U+E0Bx) glyphs in AtlasEngine.
This PR consists of 4 parts:
* AtlasEngine was refactored to simplify `_drawGlyph` because I've
wanted to do that for ~1 year now and never got a chance.
Well, now I'm doing it and you all will review it muahahaha.
The good news is that it removes a goto usage that even for my
standards was rather dangerous. Now it's gone and the risk with it.
* AtlasEngine was further refactored to properly parse out text that
we want to handle different from regular text. Previously, we only
did that for soft fonts, but now we want to do that for a lot more,
so a refactor was in order. The new code is still extremely
disgusting, because I now stuff `wchar_t`s into an array that's
intended for glyph indices, but that's the best way to make it fast
and not blow up the complexity of the code even further.
* Finally this adds a huge LUT for all the aforementioned glyphs.
The LUT has 4 "drawing instruction" entries per glyph which describe
the shape (rectangle, circle, lines, etc.) and the start/end coord.
With a lot of bit packing each entry is only 4 bytes large.
* Finally-finally a `builtinGlyphs` setting was added to the font
object and it defaults to `true`.
Closes#5897
## Validation Steps Performed
* RenderingTests with soft fonts ✅
* All the aforementioned glyphs ✅
* ...with color ✅
* `customGlyphs` setting can be toggled on and off ✅
`ConsoleBench` is capable of launching conhost instances and measuring
their performance characteristics. It writes these out as an HTML file
with violin graphs (using plotly.js) for easy comparison.
Currently, only a small number of tests have been added, but the code
is structured in such a way that more tests can be added easily.
This changeset makes 3 improvements:
* Dotted lines now use a 2:1 ratio between gaps and dots (from 1:1).
This makes the dots a lot easier to spot at small font sizes.
* Dashed lines use a 1:2 ratio and a cells-size independent stride.
By being cell-size independent it works more consistently with a
wider variety of fonts with weird cell aspect ratios.
* Curly lines are now cell-size independent as well and have a
height that equals the double-underline size.
This ensures that the curve isn't cut off anymore and just like
with dashed lines, that it works under weird aspect ratios.
Closes#16712
## Validation Steps Performed
This was tested using RenderingTests using Cascadia Mono, Consolas,
Courier New, Lucida Console and MS Gothic.
With AtlasEngine being fairly stable at this point and being enabled
by default in the 1.19 branch, this changeset removes DxEngine.
## Validation Steps Performed
* WT builds and runs ✅
* WpfTestNetCore ✅
* Saving the config removes the `useAtlasEngine` key ✅
## Summary of the Pull Request
This PR adds support for the missing operations that are required in the
8-bit interface architecture extension.
`DECAUPSS` - Assign User-Preference Supplemental Set
`DECRQUPSS` - Request User-Preference Supplemental Set
`ACS` - Announce Code Structure for ANSI levels 1, 2, and 3
## Detailed Description of the Pull Request / Additional comments
For the UPSS assignment there's a new `wstring_view` in `TerminalOutput`
that tracks the current mapping table for the character set, and a new
`VTID` field tracking the ID so it can be queried. The ANSI conformance
just required a couple of calls to existing methods to designate the
appropriate character sets and GL/GR maps.
And now that we've implemented everything that's required, I've updated
our device attributes report (`DA1`) to indicate support for the 8-bit
interface architecture (feature 14).
This PR also addresses some issues with the way the 8-bit GR capability
is managed. Previously a soft reset (`DECSTR`) would return the code
page to its startup state, and the restore cursor operation (`DECRC`)
could have a similar effect. This was a problem for 8-bit apps that
weren't expecting that behavior.
I've now made it so those operations no longer have any effect on the
code page, and the same applies to the C1 parsing option (`DECAC1`). The
only way to restore the code page and C1 parsing to their startup state
now is with a hard reset (`RIS`).
## Validation Steps Performed
I've added unit tests covering the `DECAUPSS` and `DECRQUPSS` sequences,
and I've also manually tested their behavior in Vttest.
## PR Checklist
- [x] Closes#16546
- [x] Tests added/passed
There's an apparent miscompilation of `dynamic_bitset` on x86 with
MSVC 19.38, where the following code:
```cpp
dynamic_bitset<uint64_t> bits(80 * 24, 0);
bits.set(0, 3 * 80, true);
```
is expected to set the first 3.75 blocks to 1 which should produce
the following blocks:
```
0xffffffffffffffff
0xffffffffffffffff
0xffffffffffffffff
0x0000ffffffffffff
```
but it actually produces:
```
0xffffffffffffffff
0x00000000ffffffff
0xffffffffffffffff
0x0000ffffffffffff
```
The weird thing here is that this only happens if `til::bitmap`
uses a `dynamic_bitset<uint64_t>`. As soon as it uses `<uint32_t>`
any other instantiation of `<uint64_t>` is magically fixed.
Conclusion: Use `size_t` until we know what's going on.
Last known good CL version: 14.37.32822
Current broken CL version: 14.38.33130
## Validation Steps Performed
The following test completes successfully again:
```cpp
til::bitmap map{ { 80, 24 } };
map.translate({ 0, 3 }, true);
VERIFY_ARE_EQUAL(3u, map.runs().size());
```
(cherry picked from commit d3ec47a7fc)
Service-Card-Id: 91885583
Service-Version: 1.19
There's an apparent miscompilation of `dynamic_bitset` on x86 with
MSVC 19.38, where the following code:
```cpp
dynamic_bitset<uint64_t> bits(80 * 24, 0);
bits.set(0, 3 * 80, true);
```
is expected to set the first 3.75 blocks to 1 which should produce
the following blocks:
```
0xffffffffffffffff
0xffffffffffffffff
0xffffffffffffffff
0x0000ffffffffffff
```
but it actually produces:
```
0xffffffffffffffff
0x00000000ffffffff
0xffffffffffffffff
0x0000ffffffffffff
```
The weird thing here is that this only happens if `til::bitmap`
uses a `dynamic_bitset<uint64_t>`. As soon as it uses `<uint32_t>`
any other instantiation of `<uint64_t>` is magically fixed.
Conclusion: Use `size_t` until we know what's going on.
Last known good CL version: 14.37.32822
Current broken CL version: 14.38.33130
## Validation Steps Performed
The following test completes successfully again:
```cpp
til::bitmap map{ { 80, 24 } };
map.translate({ 0, 3 }, true);
VERIFY_ARE_EQUAL(3u, map.runs().size());
```
Write "<command that doesn't exist> foo" in cmd.exe, move yours cursor
past the <command> and press tab. The "foo" will still be there but
will be inaccessible. This commit fixes the issue. As far as I can
tell, this never worked in any conhost version ever.
Closes#16704
(cherry picked from commit 5e9f223a6c)
Service-Card-Id: 91851714
Service-Version: 1.19
Write "<command that doesn't exist> foo" in cmd.exe, move yours cursor
past the <command> and press tab. The "foo" will still be there but
will be inaccessible. This commit fixes the issue. As far as I can
tell, this never worked in any conhost version ever.
Closes#16704
Changes recently landed in `ge_release_we_adept_dev` that result in
conhost loading `Windows.Storage.dll` during startup, rather than
`shell32`. This causes a memory usage regression.
The only thing we need from `shell32` during startup is
`ExtractIconExW`. Fortunately, that function is relatively simple and
it relies only on things from `user32` (and one thing from `comctl32`).
Enclosed herein is an implementation of `ExtractIconExW` that is tuned
for conhost's specific use case and tidied up.
Related work items: MSFT-48947348
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/ge_release_we_adept_dev c54c102a362c3dbc7a64cc148b45b993b4154ead
## Summary of the Pull Request
Implements an `ActionsViewModel` for the `Actions` page in the SUI
## References
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over
[here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign
the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on
[our docs repo](https://github.com/MicrosoftDocs/terminal) and link it
here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
A few annoyances:
- Because of the shifts in the UI when switching between edit
mode/regular mode on the `KeyBindingViewModel`s, the page used to
manually handle moving focus accordingly so that focus does not get
lost. However, the page no longer owns the `KeyBindingViewModel`,
instead the `ActionsViewModel` owns them but the `ActionsViewModel`
cannot manually move focus around since it does not own the UI Element.
So, the `ActionsViewModel` emits an event for the page to catch that
tells the page to move focus (`FocusContainer`).
- Similarly, the page used to manually update the `ContainerBackground`
of the `KeyBindingViewModel` when the kbdVM enters `EditMode`. The
`ActionsViewModel` does not have access to the page's resources though
(to determine the correct background brush to use). So, the
`ActionsViewModel` emits another event for the page to catch
(`UpdateBackground`).
## Validation Steps Performed
Actions page still works as before
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
Hi, I realized I had a bug in my pull request for search selections
where when the highlight is wrapped it causes the selection to select
back to start of the current line instead of wrapping to the next line.
PR where I introduced this bug: #16227
Dustin L. Howett