Merge branch 'dev/migrie/f/sui-panes' into dev/migrie/fhl/tasks-pane

.github/actions/spelling/allow/allow.txt

@@ -14,6 +14,7 @@ changelog
 clickable
 clig
 CMMI
+consvc
 copyable
 Counterintuitively
 CtrlDToClose

.github/actions/spelling/excludes.txt

@@ -126,3 +126,4 @@
 ^tools/ReleaseEngineering/ServicingPipeline\.ps1$
 ^XamlStyler\.json$
 ignore$
+Resources/(?!en)

.github/actions/spelling/expect/expect.txt

@@ -74,6 +74,7 @@ aumid
 Authenticode
 AUTOBUDDY
 AUTOCHECKBOX
+autocrlf
 autohide
 AUTOHSCROLL
 automagically

build/pipelines/daily-loc-submission.yml

@@ -8,6 +8,12 @@ schedules:
         - main
     always: false # only run if there's code changes!
 
+
+parameters:
+  - name: targetBranch
+    type: string
+    default: "automated/loc-update"
+
 pool:
   vmImage: windows-2019
 
@@ -38,6 +44,13 @@ steps:
   persistCredentials: true
   path: s/Terminal.Internal
 
+- pwsh: |-
+    Install-Module PSGitHub -Scope CurrentUser -Force
+    git config --local user.email "consvc@microsoft.com"
+    git config --local user.name "Console Service Bot"
+    git config --local core.autocrlf true
+  displayName: Prepare git submission environment
+
 - task: MicrosoftTDBuild.tdbuild-task.tdbuild-task.TouchdownBuildTask@1
   displayName: 'Touchdown Build - 7105, PRODEXT'
   inputs:
@@ -51,13 +64,44 @@ steps:
     outputDirectoryRoot: LocOutput
     appendRelativeDir: true
     pseudoSetting: Included
+    localizationTarget: true
 
-# Saving one of these makes it really easy to inspect the loc output...
-- powershell: 'tar czf LocOutput.tar.gz LocOutput'
-  displayName: 'Archive Loc Output for Submission'
+- pwsh: |-
+    Remove-Item -EA:Ignore -R -Force LocOutput\Terminal.Internal
+    $Files = Get-ChildItem LocOutput -R -Include 'ContextMenu.resw','Resources.resw' | ? FullName -Like '*en-US\*\*.resw'
+    $Files | % { Move-Item -Verbose $_.Directory $_.Directory.Parent.Parent -EA:Ignore }
+    & tar.exe -c -f LocOutputMunged.tar -C LocOutput .
+    & tar.exe -x -v -f LocOutputMunged.tar
+    rm LocOutputMunged.tar
+    rm -r -fo LocOutput
+    & ./build/scripts/Copy-ContextMenuResourcesToCascadiaPackage.ps1
+  displayName: Move Loc files to the right places
 
-- task: PublishBuildArtifacts@1
-  displayName: 'Publish Artifact: LocOutput'
-  inputs:
-    PathtoPublish: LocOutput.tar.gz
-    ArtifactName: LocOutput
+- pwsh: |-
+    git add **/*.resw
+    git status
+    git diff --quiet --cached --exit-code
+    If ($LASTEXITCODE -Ne 0) {
+      $Now = Get-Date
+      git commit -m "Localization Updates - $Now"
+      git push origin HEAD:refs/heads/${{parameters.targetBranch}} -f
+      Write-Host "##vso[task.setvariable variable=ChangesPushedToRepo]1"
+    } Else {
+      Write-Host "##vso[task.setvariable variable=ChangesPushedToRepo]0"
+    }
+  displayName: git commit and push
+
+- pwsh: |-
+    Import-Module PSGitHub
+    $BaseBranch = "$(Build.SourceBranch)" -Replace "^refs/heads/",""
+    Write-Host "Preparing PR against $BaseBranch"
+    $PSDefaultParameterValues['*GitHub*:Owner'] = "microsoft"
+    $PSDefaultParameterValues['*GitHub*:RepositoryName'] = "terminal"
+    $PSDefaultParameterValues['*GitHub*:Token'] = ("$(GithubPullRequestToken)" | ConvertTo-SecureString -AsPlainText -Force)
+    $existingPr = Get-GitHubPullRequest -HeadBranch "${{parameters.targetBranch}}" -BaseBranch $BaseBranch
+    If ($null -Eq $existingPr) {
+      $Now = Get-Date
+      New-GitHubPullRequest -Head "${{parameters.targetBranch}}" -Base $BaseBranch -Title "Localization Updates - $BaseBranch - $Now" -Verbose
+    }
+  displayName: Publish pull request
+  condition: and(eq(variables['ChangesPushedToRepo'], '1'), succeeded())

build/pipelines/templates-v2/pipeline-full-release-build.yml

@@ -104,10 +104,6 @@ stages:
                 packageListDownload: e82d490c-af86-4733-9dc4-07b772033204
                 versionListDownload: ${{ parameters.terminalInternalPackageVersion }}
 
-            - template: ./steps-fetch-and-prepare-localizations.yml
-              parameters:
-                includePseudoLoc: true
-
       - ${{ if eq(parameters.buildWPF, true) }}:
         # Add an Any CPU build flavor for the WPF control bits
         - template: ./job-build-project.yml

build/pipelines/templates-v2/pipeline-onebranch-full-release-build.yml

@@ -131,10 +131,6 @@ extends:
                     packageListDownload: e82d490c-af86-4733-9dc4-07b772033204
                     versionListDownload: ${{ parameters.terminalInternalPackageVersion }}
 
-                - template: ./build/pipelines/templates-v2/steps-fetch-and-prepare-localizations.yml@self
-                  parameters:
-                    includePseudoLoc: true
-
           - ${{ if eq(parameters.buildWPF, true) }}:
             # Add an Any CPU build flavor for the WPF control bits
             - template: ./build/pipelines/templates-v2/job-build-project.yml@self

build/scripts/Copy-ContextMenuResourcesToCascadiaPackage.ps1

@@ -10,11 +10,12 @@ $LocalizationsFromContextMenu | ForEach-Object {
 ForEach ($pair in $Languages.GetEnumerator()) {
 	$LanguageDir = "./src/cascadia/CascadiaPackage/Resources/$($pair.Key)"
 	$ResPath = "$LanguageDir/Resources.resw"
+	$XmlDocument = $null
 	$PreexistingResw = Get-Item $ResPath -EA:Ignore
 	If ($null -eq $PreexistingResw) {
 		Write-Host "Copying $($pair.Value.FullName) to $ResPath"
+		$XmlDocument = [xml](Get-Content $pair.Value.FullName)
 		New-Item -type Directory $LanguageDir -EA:Ignore
-		Copy-Item $pair.Value.FullName $ResPath
 	} Else {
 		# Merge Them!
 		Write-Host "Merging $($pair.Value.FullName) into $ResPath"
@@ -29,6 +30,19 @@ ForEach ($pair in $Languages.GetEnumerator()) {
 		$newXml.root.data | % {
 			$null = $existingXml.root.AppendChild($existingXml.ImportNode($_, $true))
 		}
-		$existingXml.Save($PreexistingResw.FullName)
+		$XmlDocument = $existingXml # (which has been updated)
 	}
+
+	# Reset paths to be absolute (for .NET)
+	$LanguageDir = (Get-Item $LanguageDir).FullName
+	$ResPath = "$LanguageDir/Resources.resw"
+	# Force the "new" and "preexisting" paths to serialize with XmlWriter,
+	# to ensure consistency.
+	$writerSettings = [System.Xml.XmlWriterSettings]::new()
+	$writerSettings.NewLineChars = "`r`n"
+	$writerSettings.Indent = $true
+	$writer = [System.Xml.XmlWriter]::Create($ResPath, $writerSettings)
+	$XmlDocument.Save($writer)
+	$writer.Flush()
+	$writer.Close()
 }

doc/specs/#6899 - Action IDs/#6899 - Action IDs.md

@@ -23,7 +23,7 @@ contexts without needing to replicate an entire json blob.
 
 This spec was largely inspired by the following diagram from @DHowett:
 
-![figure 1](data-mockup.png)
+![figure 1](data-mockup-002.png)
 
 The goal is to introduce an `id` parameter by which actions could be uniquely
 referred to. If we'd ever like to use an action outside the list of `actions`, we
@@ -36,38 +36,54 @@ Discussion with the team lead to the understanding that the name `actions` would
 be even better, as a way of making the meaning of the "list of actions" more
 obvious.
 
-When we're parsing `actions`, we'll make three passes:
-* The first pass will scan the list for objects with an `id` property. We'll
+We will then restructure `defaults.json`, and also users' settings files (via `fixUpUserSettings`), in the following manner:
+* Instead of each `command` json block containing both the `action` (along with additional arguments) and the `keys`, these will now be split up -
+    * There will now be one json block for just the `command`/`action`, which will also contain the `id`. These json blocks will be in their own list called `actions`.
+    * There will be another json block for the `keys`, which will refer to the action to be invoked by `id`. These json blocks will be in their own list called `keybindings`.
+
+For example, let's take a look at the `split pane right` action in `defaults.json` as we currently have it:
+
+`"actions": [..., { "command": { "action": "splitPane", "split": "right" }, "keys": "alt+shift+plus" }, ...]`
+
+This will now become:
+
+`"actions": [..., { "command": { "action": "splitPane", "split": "right" }, "id": "Terminal.SplitPaneRight" }, ...]`
+
+`"keybindings": [..., { "keys": "alt+shift+plus", "id": "Terminal.SplitPaneRight" }, ...]`
+
+Here is how we will parse settings file and construct the relevant settings model objects:
+* We will first scan the `actions` list. We'll
   attempt to parse those entries into `ActionAndArgs` which we'll store in the
-  global `id->ActionAndArgs` map. If any entry doesn't have an `id` set, we'll
-  skip it in this phase. If an entry doesn't have a `command` set, we'll ignore
-  it in this pass.
-* The second pass will scan for _keybindings_. Any entries with `keys` set will
-  create a `KeyChord->ActionAndArgs` entry in the keybindings map. If the entry
-  has an `id` set, then we'll simply re-use the action we've already parsed for
-  the `id`, from the action map. If there isn't an `id`, then we'll parse the
-  action manually at this time. Entries without a `keys` set will be ignored in
-  this pass.
-* The final pass will be to generate _commands_. Similar to the keybindings
-  pass, we'll attempt to lookup actions for entries with an `id` set. If there
-  isn't an `id`, then we'll parse the action manually at this time. We'll then
-  get the name for the entry, either from the `name` property if it's set, or
-  the action's `GenerateName` method.
+  global `id->ActionAndArgs` map. All actions defined in `defaults.json` must have an `id` specified, and all actions provided by fragments must also have `id`s. Any actions from the defaults or fragments that do not provide `id`s will be ignored. As for user-specified commands, if no `id` is set, we will auto-generate one for that command based on the action and any additional arguments. For example, the `split pane right` command above might result in an autogenerated id `User.SplitPaneRight`.
+    * Note: this step is also where we will generate _commands_. We will use the name provided in the entry if it's set or the action's `GenerateName` method.
+* Next we will scan the `keybindings` list. These entries will
+  create a `KeyChord->ActionAndArgs` entry in the keybindings map. Since these objects should all contain an `id`, we will simply use the `id->ActionAndArgs` map we created in the previous step. Any object with `keys` set but no `id` will be ignored.
 
-For a visual representation, let's assume the user has the following in their
-`actions`:
+For a visual representation:
 
-![figure 2](data-mockup-actions.png)
+![figure 2](data-mockup-actions-ids-keys-maps.png)
 
-We'll first parse the `actions` to generate the mapping of `id`->`Actions`:
+### Nested actions
 
-![figure 3](data-mockup-actions-and-ids.png)
+We allow certain actions that take a form like this:
 
-Then, we'll parse the `actions` to generate the mapping of keys to actions, with
-some actions already being defined in the map of `id`->`Actions`:
+```
+        {
+            // Select color scheme...
+            "name": { "key": "SetColorSchemeParentCommandName" },
+            "commands": [
+                {
+                    "iterateOn": "schemes",
+                    "name": "${scheme.name}",
+                    "command": { "action": "setColorScheme", "colorScheme": "${scheme.name}" }
+                }
+            ]
+        }
+```
 
-![figure 4](data-mockup-actions-and-ids-and-keys.png)
+For this case, having an `id` on the top level could potentially make sense when it comes to using that `id` in a menu, but not in the case of using that `id` for a keybinding. For the initial implementation, we will not support an `id` for these types of actions, which leaves us open to revisiting this in the future.
 
+### Layering
 
 When layering `actions`, if a later settings file contains an action with the
 same `id`, it will replace the current value. In this way, users can redefine
@@ -87,6 +103,9 @@ As we add additional menus to the Terminal, like the customization for the new
 tab dropdown, or the tab context menu, or the `TermControl` context menu, they
 could all refer to these actions by `id`, rather than duplicating the same json.
 
+As for fragments, all actions in fragments _must_ have an `id`. If a fragment provides an action without an `id`, or provides an `id` that clashes with one of the actions in `defaults.json`, that action will be ignored.
+
+> 👉 NOTE: This will mean that actions will now need an `OriginTag`, similar to profiles and color schemes
 
 ### Existing Scenarios
 

samples/PixelShaders/BackgroundImage.hlsl

@@ -0,0 +1,23 @@
+// Demo shader to show passing in an image using
+// experimental.pixelShaderImagePath. This shader simply displays the Terminal
+// contents on top of the given image.
+//
+// The image loaded by the terminal will be placed into the `image` texture.
+
+SamplerState samplerState;
+Texture2D shaderTexture : register(t0);
+Texture2D image : register(t1);
+
+cbuffer PixelShaderSettings {
+    float Time;
+    float Scale;
+    float2 Resolution;
+    float4 Background;
+};
+
+float4 main(float4 pos : SV_POSITION, float2 tex : TEXCOORD) : SV_TARGET
+{
+    float4 terminalColor = shaderTexture.Sample(samplerState, tex);
+    float4 imageColor = image.Sample(samplerState, tex);
+    return lerp(imageColor, terminalColor, terminalColor.a);
+}