maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/src/cascadia/TerminalApp/TerminalAppLib.vcxproj

406 lines
19 KiB
XML
Raw Normal View History

Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Unify and clean up the common build properties (#3429) This commit cleans up and deduplicates all of the common build preamble/postamble across exe, dll, lib and c++/winrt projects. The following specific changes have been made: * All projects now define their ConfigurationType * All projects now set all their properties *before* including a common build file (or any other build files) * cppwinrt.pre and cppwinrt.post now delegate most of their configuration to common.pre and common.post * (becuase of the above,) all build options are conserved between console and c++/winrt components, including specific warnings and preprocessor definitions. * More properties that are configurable per-project are now conditioned so the common props don't override them. * The exe, dll, exe.or.dll, and lib postincludes have been merged into pre or post and switched based on condition as required * Shared items (-shared, -common) are now explicitly vcxitems instead of vcxproj files. * The link line is now manipulated after Microsoft.Cpp sets it, so the libraries we specify "win". All console things link first against onecore_apiset.lib. * Fix all compilation errors caused by build unification * Move CascadiaPackage's resources into a separate item file Fixes #922.
2019-11-05 23:29:11 +01:00
<PropertyGroup Label="Globals">
<ProjectGuid>{CA5CAD1A-9A12-429C-B551-8562EC954746}</ProjectGuid>
<Keyword>Win32Proj</Keyword>
<RootNamespace>TerminalApp</RootNamespace>
<ProjectName>TerminalAppLib</ProjectName>
<TargetName>TerminalAppLib</TargetName>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<ConfigurationType>StaticLibrary</ConfigurationType>
<SubSystem>Console</SubSystem>
<OpenConsoleUniversalApp>true</OpenConsoleUniversalApp>
<!--
This is an override that, puzzlingly, _forces XBF (XAML binary) embedding_.
We have to do this to overcome a layout issue in the WAP packaging project.
When we do this, the XBF ends up in resources.pri.
-->
<DisableEmbeddedXbf>false</DisableEmbeddedXbf>
Set the ComponentResourceLocation for our DLL projects (#5031) These projects load Xaml components that have Uids, but those Uids just weren't working because Xaml components are, by default, loaded in "Application" scope. Application scope is great if the resource producer is the EXE project. Application scope means that resources are looked up at the resource root, but DLLs with resources don't produce resources at the root. They produce resources at a root named after the DLL. Setting the Xaml component resource location to Nested makes sure the Xaml resource loader loads resources from the right places.
2020-03-20 21:08:32 +01:00
<XamlComponentResourceLocation>nested</XamlComponentResourceLocation>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</PropertyGroup>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Import Project="..\..\..\common.openconsole.props" Condition="'$(OpenConsoleDir)'==''" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.pre.props" />
Update Win32 Toolkit (6.1.2) and VCRT Forwarders (1.0.4) (#8501) There's a handful of small changes in these updates: The Win32 Toolkit is now built with CFG (I think), and the VCRT forwarders are now the (second) non-RC version.
2020-12-10 02:30:00 +01:00
<Import Project="..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.props" Condition="Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.props')" />
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
<ItemDefinitionGroup>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
Add support for commandline args to `wt.exe` (#4023) ## Summary of the Pull Request Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495 ## References * Original issue: #607 * Original spec: #3495 ## PR Checklist * [x] Closes #607 * [x] I work here * [x] Tests added/passed * [ ] We should probably add some docs on these commands * [x] The spec (#3495) needs to be merged first! ## Detailed Description of the Pull Request / Additional comments 🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now. This PR adds support for three initial sub-commands to the `wt.exe` application: * `new-tab`: Used to create a new tab. * `split-pane`: Used to create a new split. * `focus-tab`: Moves focus to another tab. These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands Important scenarios added: * `wt -d .`: Open a new wt instance in the current working directory #878 * `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339 * `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756 ## Validation Steps Performed * Ran tests * Played with it a bunch
2020-01-27 16:34:12 +01:00
<ClCompile>
<!-- For CLI11: It uses dynamic_cast to cast types around, which depends
on being compiled with RTTI (/GR). -->
<RuntimeTypeInfo>true</RuntimeTypeInfo>
</ClCompile>
</ItemDefinitionGroup>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<!-- ========================= XAML files ======================== -->
<ItemGroup>
<!-- HERE BE DRAGONS:
For any types that use XAML information, if their .idl and .h aren't
marked DependentUpon the corresponding .xaml file, XamlTypeInfo.g.h won't
pick it up correctly. -->
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ApplicationDefinition Include="App.xaml">
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Designer</SubType>
</ApplicationDefinition>
</ItemGroup>
<!-- When we add other user controls, they should go in here as so: -->
<ItemGroup>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="MinMaxCloseControl.xaml">
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Designer</SubType>
</Page>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="TerminalPage.xaml">
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Designer</SubType>
</Page>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="TitlebarControl.xaml">
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
<SubType>Designer</SubType>
</Page>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="TabRowControl.xaml">
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
<SubType>Designer</SubType>
Make tab header a custom control (#8227) This PR makes the Header of TabViewItem a custom user control. ## Validation Steps Performed Manual testing Closes #8201
2020-11-20 18:16:38 +01:00
</Page>
<Page Include="TabHeaderControl.xaml">
<SubType>Designer</SubType>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
</Page>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<Page Include="HighlightedTextControl.xaml">
<SubType>Designer</SubType>
</Page>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="ColorPickupFlyout.xaml">
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
<SubType>Designer</SubType>
</Page>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Page Include="CommandPalette.xaml">
Add support for the Command Palette (#6635) ## Summary of the Pull Request ![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif) This adds a first iteration on the command palette. Notable missing features are: * Commandline mode: This will be a follow-up PR, following the merge of #6537 * nested and iterable commands: These will additionally be a follow-up PR. This is also additionally based off the addenda in #6532. This does not bind a key for the palette by default. That will be done when the above follow-ups are completed. ## References * #2046 - The original command palette thread * #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work * #5674 and #6532 - specs * #6537 - related ## PR Checklist * [x] Closes #2046 - incidentally also closes #6645 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - delaying this until it's more polished. ## Detailed Description of the Pull Request / Additional comments * There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`. ## Validation Steps Performed * I've been playing with this for months. * Tests * Selfhost with the team
2020-06-26 22:38:02 +02:00
<SubType>Designer</SubType>
</Page>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ========================= Headers ======================== -->
<ItemGroup>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClInclude Include="ActionPaletteItem.h" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="App.base.h" />
<ClInclude Include="AppCommandlineArgs.h" />
<ClInclude Include="Commandline.h" />
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClInclude Include="CommandLinePaletteItem.h" />
Add profiles to the Jumplist (#7515) This commit introduces Jumplist customization and an item for each profile to the Jumplist. Selecting an entry in the jumplist will pretty much just execute `wt.exe -p "{profile guid}"`, and so a new Terminal will open with the selected profile. Closes #576
2020-09-04 01:35:41 +02:00
<ClInclude Include="Jumplist.h" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="MinMaxCloseControl.h">
<DependentUpon>MinMaxCloseControl.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ClInclude>
Introduce zoom, bell and progress indicators to ATS (#9041) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8912 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments * Introduced separate DataTemplate for rendering TabPaletteItem * Introduced DataTemplateSelector assigning this template * Introduced indicators as observable properties of the terminal Tab * Bound TabPaletteItem to these properties * Ensured that BindingUpdate is always called on CmdPal to avoid races
2021-02-08 18:37:58 +01:00
<ClInclude Include="PaletteItemTemplateSelector.h">
<DependentUpon>PaletteItemTemplateSelector.idl</DependentUpon>
<SubType>Code</SubType>
</ClInclude>
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<ClInclude Include="SettingsTab.h">
<DependentUpon>SettingsTab.idl</DependentUpon>
</ClInclude>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClInclude Include="PaletteItem.h" />
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<ClInclude Include="TabBase.h">
<DependentUpon>TabBase.idl</DependentUpon>
</ClInclude>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClInclude Include="TabPaletteItem.h" />
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<ClInclude Include="TerminalTab.h">
<DependentUpon>TerminalTab.idl</DependentUpon>
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="TerminalPage.h">
<DependentUpon>TerminalPage.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Code</SubType>
</ClInclude>
Fix ATS tab status indicators (#9076) 1. Fix progress value not updated 2. Introduce TabStatus object and bind both TabHeaderControl and CommandPalette to it 3. Add support for read-only mode indicator
2021-02-10 12:27:29 +01:00
<ClInclude Include="TerminalTabStatus.h">
<DependentUpon>TerminalTabStatus.idl</DependentUpon>
<SubType>Code</SubType>
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="TitlebarControl.h">
<DependentUpon>TitlebarControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="TabRowControl.h">
<DependentUpon>TabRowControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
</ClInclude>
Make tab header a custom control (#8227) This PR makes the Header of TabViewItem a custom user control. ## Validation Steps Performed Manual testing Closes #8201
2020-11-20 18:16:38 +01:00
<ClInclude Include="TabHeaderControl.h">
<DependentUpon>TabHeaderControl.xaml</DependentUpon>
</ClInclude>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<ClInclude Include="HighlightedTextControl.h">
<DependentUpon>HighlightedTextControl.xaml</DependentUpon>
</ClInclude>
<ClInclude Include="HighlightedText.h" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="ColorPickupFlyout.h">
<DependentUpon>ColorPickupFlyout.xaml</DependentUpon>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="CommandPalette.h">
<DependentUpon>CommandPalette.xaml</DependentUpon>
Add support for the Command Palette (#6635) ## Summary of the Pull Request ![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif) This adds a first iteration on the command palette. Notable missing features are: * Commandline mode: This will be a follow-up PR, following the merge of #6537 * nested and iterable commands: These will additionally be a follow-up PR. This is also additionally based off the addenda in #6532. This does not bind a key for the palette by default. That will be done when the above follow-ups are completed. ## References * #2046 - The original command palette thread * #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work * #5674 and #6532 - specs * #6537 - related ## PR Checklist * [x] Closes #2046 - incidentally also closes #6645 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - delaying this until it's more polished. ## Detailed Description of the Pull Request / Additional comments * There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`. ## Validation Steps Performed * I've been playing with this for months. * Tests * Selfhost with the team
2020-06-26 22:38:02 +02:00
</ClInclude>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<ClInclude Include="FilteredCommand.h" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="EmptyStringVisibilityConverter.h">
<DependentUpon>EmptyStringVisibilityConverter.idl</DependentUpon>
Add some polish to nested commands in the command palette (#7299) ## Summary of the Pull Request ![cmdpal-nested-command-polish](https://user-images.githubusercontent.com/18356694/90293616-1f29ca00-de4a-11ea-8942-00d255de929a.gif) * Add a chevron for nested commands * Add the text of the parent command when entering a child command ## References ## PR Checklist * [x] Closes #7265 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed _look at that gif_
2020-08-18 21:32:17 +02:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="Pane.h" />
<ClInclude Include="ColorHelper.h" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<ClInclude Include="pch.h" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="ShortcutActionDispatch.h">
<DependentUpon>ShortcutActionDispatch.idl</DependentUpon>
Encapsulate dispatching `ShortcutActions` in it's own class (#3658) ## Summary of the Pull Request Moves all the code responsible for dispatching an `ActionAndArgs` to it's own class, `ShortcutActionDispatch`. Now, the `AppKeyBindings` just uses the single instance of a `ShortcutActionDispatch` that the `TerminalPage` owns to dispatch events, without the need to re-attach the event handlers every time we reload the settings. ## References This is something I originally did as a part of #2046. I need this now for #607. It's also a part of work for #3475 ## PR Checklist * [x] This is a bullet point within #3475 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments With this change, we'll be able to have other things dispatch `ShortcutAction`s easily, by constructing an `ActionAndArgs` and just passing it straight to the `ShortcutActionDispatch`. ## Validation Steps Performed Ran the Terminal, tried out some keybindings, namely <kbd>Ctrl+c</kbd> for copy when there is a selection, or send `^C` when there isn't. That still works. Reloading settings also still works. ----------------------------------------------- * Move action handling to it's own class separate from AKB. This is the first checkbox in #3475 (cherry picked from commit 696726b571d3d1fdf1d59844c76e182fc72cb2ea) * clean up doc comments
2019-11-27 22:51:38 +01:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="DebugTapConnection.h" />
<ClInclude Include="AppKeyBindings.h">
<DependentUpon>AppKeyBindings.idl</DependentUpon>
Don't copy text if there's no selection (#2446) This commit also transitions our keybinding events and event handlers to a TypedEventHandler model with an "event args" class, as specified in the keybinding arguments specification (#1349). In short, every event can be marked Handled independently, and a Handled event will stop bubbling out to the terminal. An unhandled event will be passed off to the terminal as a standard keypress. This unifies our keybinding event model and provides a convenient place for binding arguments to live. Fixes #2285. Related to #1349, #1142.
2019-08-17 00:43:51 +02:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="App.h">
<DependentUpon>App.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ClInclude>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClInclude Include="AppLogic.h">
<DependentUpon>AppLogic.idl</DependentUpon>
Break everything out of App except Xaml platform init (#3465) This commit breaks everything out of App except the base initialization for XAML. AppLogic is the new home for all terminal-specific singleton magic.
2019-11-07 22:10:58 +01:00
</ClInclude>
Add an action for identifying windows (#9523) ## Summary of the Pull Request This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions: * `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default. ![identify-window-toast-000](https://user-images.githubusercontent.com/18356694/111529085-bf710580-872f-11eb-8880-b0b617596cfc.gif) * `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky. ![teaching-tip-dismiss-001](https://user-images.githubusercontent.com/18356694/111529292-fe06c000-872f-11eb-8d4a-5688e4ce1175.gif) That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382 Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows` ## References ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?" Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
2021-03-30 18:08:03 +02:00
<ClInclude Include="Toast.h"/>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ========================= Cpp Files ======================== -->
<ItemGroup>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClCompile Include="ActionPaletteItem.cpp" />
<ClCompile Include="CommandLinePaletteItem.cpp" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="init.cpp" />
<ClCompile Include="AppCommandlineArgs.cpp" />
<ClCompile Include="Commandline.cpp" />
Add profiles to the Jumplist (#7515) This commit introduces Jumplist customization and an item for each profile to the Jumplist. Selecting an entry in the jumplist will pretty much just execute `wt.exe -p "{profile guid}"`, and so a new Terminal will open with the selected profile. Closes #576
2020-09-04 01:35:41 +02:00
<ClCompile Include="Jumplist.cpp" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="MinMaxCloseControl.cpp">
<DependentUpon>MinMaxCloseControl.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ClCompile>
Introduce zoom, bell and progress indicators to ATS (#9041) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8912 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments * Introduced separate DataTemplate for rendering TabPaletteItem * Introduced DataTemplateSelector assigning this template * Introduced indicators as observable properties of the terminal Tab * Bound TabPaletteItem to these properties * Ensured that BindingUpdate is always called on CmdPal to avoid races
2021-02-08 18:37:58 +01:00
<ClCompile Include="PaletteItemTemplateSelector.cpp">
<DependentUpon>PaletteItemTemplateSelector.idl</DependentUpon>
<SubType>Code</SubType>
</ClCompile>
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<ClCompile Include="SettingsTab.cpp">
<DependentUpon>SettingsTab.idl</DependentUpon>
</ClCompile>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClCompile Include="PaletteItem.cpp" />
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<ClCompile Include="TabBase.cpp">
<DependentUpon>TabBase.idl</DependentUpon>
</ClCompile>
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<ClCompile Include="TabPaletteItem.cpp" />
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<ClCompile Include="TerminalTab.cpp">
<DependentUpon>TerminalTab.idl</DependentUpon>
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="TerminalPage.cpp">
<DependentUpon>TerminalPage.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Code</SubType>
</ClCompile>
minor refactor: Move Tab management into its own file (#9629) I think we can all agree that `TerminalPage.cpp` is an unruly beast of a file. It's got everything. It does everything. It can sometimes be a bit hard to work with, because of simply how big it is. This PR tries to alleviate this by making `TerminalPage.cpp` just a little smaller. It does so by moving pretty much everything related to tab management into its own file, `TabManagement.cpp`. These methods that have moved are all the same as they were before, and they're still members of `TerminalPage`. But now they're all in one place. I tried to move all the references to `_tabs` in `TerminalPage.cpp`, but there's still a few that I left behind. Mostly because I felt that moving those would be too gnarly a code change for an otherwise simple cut&paste PR. There are a few new methods I introduced: * `_TabDragStarted` and `_TabDragCompleted`: These were lambdas before, promoted to full methods. * `_DismissTabContextMenus`: Remove all the right-click context menus from the tabs * `_FocusCurrentTab`: This one's a bit trickier, we were actually doing this in a few different places, so I tried consolidating. * `_HasMultipleTabs`: This doesn't need explaining. * `_RemoveAllTabs`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` * `_ResizeTabContent`: Really, just encapsulation for the sake of removing a `_tabs` from `TerminalPage.cpp` In the future, some enterprising young soul could try promoting that file to its own class, and hiding `_tabs` (and `_mruTabs`) inside it. Probably would need to take a reference to TerminalPage's `_tabView` and `_newTabButton`. I'm not doing that right now, because I already hate the idea of the ... > 920 additions and 847 deletions. ... I'm making you look at already. ## Other thoughts Some of the calls might be a little arbitrary - `_OpenNewTab` and `_CreateNewTabFromSettings` probably should stay in `TerminalPage`? Or at least elements of those might need to get split up better. Similarly `TerminalPage::_OpenSettingsUI` stayed in `TerminalPage.cpp`, but it does a lot of the same work as `_CreateNewTabFromSettings`. I'm not saying this is the definitive places for these methods - it's code we're working with, not stone ☺️
2021-03-29 21:53:39 +02:00
<ClCompile Include="TabManagement.cpp">
<DependentUpon>TerminalPage.xaml</DependentUpon>
<SubType>Code</SubType>
</ClCompile>
Enable previewing the color scheme in the command palette (#9794) ## Summary of the Pull Request Allow schemes to be previewed as the user hovers over them in the Command Palette. ![preview-set-color-scheme](https://user-images.githubusercontent.com/18356694/114557761-9a3cbd80-9c2f-11eb-987f-eb0c89ee1fa6.gif) ## References * Branched off of #8392, which is why the commit history is so polluted. 330a8e8 : 544b2fd has the interesting commits * #5400: cmdpal megathread ### Potential follow-ups * changing the font size * changing the font face * changing the opacity of acrylic ## PR Checklist * [x] Closes #6689, a last straggling FHL PR * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated - I don't think so ## Detailed Description of the Pull Request / Additional comments This works by inserting a "preview" `TerminalSettings` into the settings hierarchy, before the `TermControl`'s runtime settings, and after the ones from the actual `CascadiaSettings`. This allows us to modify that preview settings object, then discard it when we're done with the preview. This could also be used for other settings in the future - I built it to be extensible to other `ShortcutAction`s, though I haven't implemented those yet. ## Validation Steps Performed * Select a colorscheme - it becomes the active one * `colortool -x <scheme>` after selecting a scheme - colortool overrides the selected scheme * Select a colorscheme after a `colortool -x <scheme>` after selecting a scheme - the scheme in the palette becomes the active one * Pressing <kbd>esc</kbd> at any point to dismiss the command palette - scheme returns to the previous one * reloading the settings - returns to the scheme in the settings
2021-04-21 22:35:06 +02:00
<ClCompile Include="ActionPreviewHandlers.cpp">
<DependentUpon>TerminalPage.xaml</DependentUpon>
<SubType>Code</SubType>
</ClCompile>
Fix ATS tab status indicators (#9076) 1. Fix progress value not updated 2. Introduce TabStatus object and bind both TabHeaderControl and CommandPalette to it 3. Add support for read-only mode indicator
2021-02-10 12:27:29 +01:00
<ClCompile Include="TerminalTabStatus.cpp">
<DependentUpon>TerminalTabStatus.idl</DependentUpon>
<SubType>Code</SubType>
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="TitlebarControl.cpp">
<DependentUpon>TitlebarControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="TabRowControl.cpp">
<DependentUpon>TabRowControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
</ClCompile>
Make tab header a custom control (#8227) This PR makes the Header of TabViewItem a custom user control. ## Validation Steps Performed Manual testing Closes #8201
2020-11-20 18:16:38 +01:00
<ClCompile Include="TabHeaderControl.cpp">
<DependentUpon>TabHeaderControl.xaml</DependentUpon>
</ClCompile>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<ClCompile Include="HighlightedTextControl.cpp">
<DependentUpon>HighlightedTextControl.xaml</DependentUpon>
</ClCompile>
<ClCompile Include="HighlightedText.cpp" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="ColorPickupFlyout.cpp">
<DependentUpon>ColorPickupFlyout.xaml</DependentUpon>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="CommandPalette.cpp">
<DependentUpon>CommandPalette.xaml</DependentUpon>
Add support for the Command Palette (#6635) ## Summary of the Pull Request ![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif) This adds a first iteration on the command palette. Notable missing features are: * Commandline mode: This will be a follow-up PR, following the merge of #6537 * nested and iterable commands: These will additionally be a follow-up PR. This is also additionally based off the addenda in #6532. This does not bind a key for the palette by default. That will be done when the above follow-ups are completed. ## References * #2046 - The original command palette thread * #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work * #5674 and #6532 - specs * #6537 - related ## PR Checklist * [x] Closes #2046 - incidentally also closes #6645 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - delaying this until it's more polished. ## Detailed Description of the Pull Request / Additional comments * There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`. ## Validation Steps Performed * I've been playing with this for months. * Tests * Selfhost with the team
2020-06-26 22:38:02 +02:00
</ClCompile>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<ClCompile Include="FilteredCommand.cpp" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="EmptyStringVisibilityConverter.cpp">
<DependentUpon>EmptyStringVisibilityConverter.idl</DependentUpon>
Add some polish to nested commands in the command palette (#7299) ## Summary of the Pull Request ![cmdpal-nested-command-polish](https://user-images.githubusercontent.com/18356694/90293616-1f29ca00-de4a-11ea-8942-00d255de929a.gif) * Add a chevron for nested commands * Add the text of the parent command when entering a child command ## References ## PR Checklist * [x] Closes #7265 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed _look at that gif_
2020-08-18 21:32:17 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="Pane.cpp" />
<ClCompile Include="Pane.LayoutSizeNode.cpp" />
<ClCompile Include="ColorHelper.cpp" />
<ClCompile Include="DebugTapConnection.cpp" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<ClCompile Include="pch.cpp">
<PrecompiledHeader>Create</PrecompiledHeader>
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="AppKeyBindings.cpp">
<DependentUpon>AppKeyBindings.idl</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="ShortcutActionDispatch.cpp">
<DependentUpon>ShortcutActionDispatch.idl</DependentUpon>
Encapsulate dispatching `ShortcutActions` in it's own class (#3658) ## Summary of the Pull Request Moves all the code responsible for dispatching an `ActionAndArgs` to it's own class, `ShortcutActionDispatch`. Now, the `AppKeyBindings` just uses the single instance of a `ShortcutActionDispatch` that the `TerminalPage` owns to dispatch events, without the need to re-attach the event handlers every time we reload the settings. ## References This is something I originally did as a part of #2046. I need this now for #607. It's also a part of work for #3475 ## PR Checklist * [x] This is a bullet point within #3475 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments With this change, we'll be able to have other things dispatch `ShortcutAction`s easily, by constructing an `ActionAndArgs` and just passing it straight to the `ShortcutActionDispatch`. ## Validation Steps Performed Ran the Terminal, tried out some keybindings, namely <kbd>Ctrl+c</kbd> for copy when there is a selection, or send `^C` when there isn't. That still works. Reloading settings also still works. ----------------------------------------------- * Move action handling to it's own class separate from AKB. This is the first checkbox in #3475 (cherry picked from commit 696726b571d3d1fdf1d59844c76e182fc72cb2ea) * clean up doc comments
2019-11-27 22:51:38 +01:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="App.cpp">
<DependentUpon>App.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="AppActionHandlers.cpp">
Enable previewing the color scheme in the command palette (#9794) ## Summary of the Pull Request Allow schemes to be previewed as the user hovers over them in the Command Palette. ![preview-set-color-scheme](https://user-images.githubusercontent.com/18356694/114557761-9a3cbd80-9c2f-11eb-987f-eb0c89ee1fa6.gif) ## References * Branched off of #8392, which is why the commit history is so polluted. 330a8e8 : 544b2fd has the interesting commits * #5400: cmdpal megathread ### Potential follow-ups * changing the font size * changing the font face * changing the opacity of acrylic ## PR Checklist * [x] Closes #6689, a last straggling FHL PR * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated - I don't think so ## Detailed Description of the Pull Request / Additional comments This works by inserting a "preview" `TerminalSettings` into the settings hierarchy, before the `TermControl`'s runtime settings, and after the ones from the actual `CascadiaSettings`. This allows us to modify that preview settings object, then discard it when we're done with the preview. This could also be used for other settings in the future - I built it to be extensible to other `ShortcutAction`s, though I haven't implemented those yet. ## Validation Steps Performed * Select a colorscheme - it becomes the active one * `colortool -x <scheme>` after selecting a scheme - colortool overrides the selected scheme * Select a colorscheme after a `colortool -x <scheme>` after selecting a scheme - the scheme in the palette becomes the active one * Pressing <kbd>esc</kbd> at any point to dismiss the command palette - scheme returns to the previous one * reloading the settings - returns to the scheme in the settings
2021-04-21 22:35:06 +02:00
<DependentUpon>TerminalPage.xaml</DependentUpon>
Don't copy text if there's no selection (#2446) This commit also transitions our keybinding events and event handlers to a TypedEventHandler model with an "event args" class, as specified in the keybinding arguments specification (#1349). In short, every event can be marked Handled independently, and a Handled event will stop bubbling out to the terminal. An unhandled event will be passed off to the terminal as a standard keypress. This unifies our keybinding event model and provides a convenient place for binding arguments to live. Fixes #2285. Related to #1349, #1142.
2019-08-17 00:43:51 +02:00
</ClCompile>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<ClCompile Include="AppLogic.cpp">
<DependentUpon>AppLogic.idl</DependentUpon>
Break everything out of App except Xaml platform init (#3465) This commit breaks everything out of App except the base initialization for XAML. AppLogic is the new home for all terminal-specific singleton magic.
2019-11-07 22:10:58 +01:00
</ClCompile>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<ClCompile Include="$(GeneratedFilesDir)module.g.cpp" />
Add an action for identifying windows (#9523) ## Summary of the Pull Request This is a follow up to #9300. Now that we have names on our windows, it would be nice to see who is named what. So this adds two actions: * `identifyWindow`: This action will pop up a little toast (#8592) displaying the name and ID of the window, and is bound by default. ![identify-window-toast-000](https://user-images.githubusercontent.com/18356694/111529085-bf710580-872f-11eb-8880-b0b617596cfc.gif) * `identifyWindows`: This action will request that ALL windows pop up that toast. This is meant to feel like the "Identify" button on the Windows display settings. However, sometimes, it's wonky. ![teaching-tip-dismiss-001](https://user-images.githubusercontent.com/18356694/111529292-fe06c000-872f-11eb-8d4a-5688e4ce1175.gif) That's being tracked upstream on https://github.com/microsoft/microsoft-ui-xaml/issues/4382 Because it's so wonky, we won't bind that by default. Maybe if we get that fixed, then we'll change the default binding from `identifyWindow` to `identifyWindows` ## References ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/projects/5#card-51431492 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments You may note that there are some macros to make interacting with lots and lots of actions easier. There's a lot of boilerplate whenever you need to make a new action, so I thought: "Can we make that easier?" Turns out you can make it a _LOT_ easier, but that work is still behind another PR after this one. Get excited
2021-03-30 18:08:03 +02:00
<ClCompile Include="Toast.cpp" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ========================= idl Files ======================== -->
<ItemGroup>
<!-- If you add idl files here, make sure to include their implementation's
header in TerminalApp.vcxproj (as well as in this file) -->
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<Midl Include="ActionPaletteItem.idl" />
<Midl Include="CommandLinePaletteItem.idl" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="IDirectKeyListener.idl" />
<Midl Include="App.idl">
<DependentUpon>App.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</Midl>
Introduce zoom, bell and progress indicators to ATS (#9041) ## PR Checklist * [x] Closes https://github.com/microsoft/terminal/issues/8912 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments * Introduced separate DataTemplate for rendering TabPaletteItem * Introduced DataTemplateSelector assigning this template * Introduced indicators as observable properties of the terminal Tab * Bound TabPaletteItem to these properties * Ensured that BindingUpdate is always called on CmdPal to avoid races
2021-02-08 18:37:58 +01:00
<Midl Include="PaletteItemTemplateSelector.idl">
<SubType>Designer</SubType>
</Midl>
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<Midl Include="SettingsTab.idl" />
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<Midl Include="PaletteItem.idl" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="ShortcutActionDispatch.idl" />
<Midl Include="AppKeyBindings.idl" />
<Midl Include="AppLogic.idl" />
<Midl Include="MinMaxCloseControl.idl">
<DependentUpon>MinMaxCloseControl.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Code</SubType>
</Midl>
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<Midl Include="TabBase.idl" />
Teach CommandPalette model to natively support tabs and command lines (#8420) First step towards #8415: * Introduce `PaletteItem` and derive from it to provide native support for tabs and command lines (`ActionPaletteItem` / `TabPaletteItem`, `CommandLinePaltteItem`) * Remove business logic behind PaletteItem from palette (aka dispatch commands and preview tabs externally)
2020-12-10 01:36:28 +01:00
<Midl Include="TabPaletteItem.idl" />
Make Tab an unsealed runtimeclass (and rename it to TabBase) (#8153) In preparation for the Settings UI, we needed to make some changes to Tab to abstract out shared, common functionality between different types of tab. This is the result of that work. All code references to the settings have been removed or reverted. Contains changes from #8053, #7802. The messages below only make sense in the context of the Settings UI, which this pull request does not bring in. They do, however, provide valuable information. From #7802 (@leonMSFT): > This PR's goal was to add an option to the `OpenSettings` keybinding to > open the Settings UI in a tab. In order to implement that, a couple of > changes had to be made to `Tab`, specifically: > > - Introduce a tab interface named `ITab` > - Create/Rename two new Tab classes that implement `ITab` called > `SettingsTab` and `TerminalTab` > From #8053: > `TerminalTab` and `SettingsTab` share some implementation details. The > close submenu introduced in #7728 is a good example of functionality > that is consistent across all tabs. This PR transforms `ITab` from an > interface, into an [unsealed runtime class] to de-duplicate some > functionality. Most of the logic from `SettingsTab` was moved there > because I expect the default behavior of a tab to resemble the > `SettingsTab` over a `TerminalTab`. > > ## References > Verified that Close submenu work was transferred over (#7728, #7961, #8010). > > ## Validation Steps Performed > Check close submenu on first/last tab when multiple tabs are open. > > Closes #7969 > > [unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
2020-11-04 19:15:05 +01:00
<Midl Include="TerminalTab.idl" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="TerminalPage.idl">
<DependentUpon>TerminalPage.xaml</DependentUpon>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<SubType>Code</SubType>
</Midl>
Fix ATS tab status indicators (#9076) 1. Fix progress value not updated 2. Introduce TabStatus object and bind both TabHeaderControl and CommandPalette to it 3. Add support for read-only mode indicator
2021-02-10 12:27:29 +01:00
<Midl Include="TerminalTabStatus.idl">
<SubType>Designer</SubType>
</Midl>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="TitlebarControl.idl">
<DependentUpon>TitlebarControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
<SubType>Code</SubType>
</Midl>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="TabRowControl.idl">
<DependentUpon>TabRowControl.xaml</DependentUpon>
Enable dragging with the entire titlebar (#1948) * This definitely works for getting shadow, pointy corners back Don't do anything in NCPAINT. If you do, you have to do everything. But the whole point of DwmExtendFrameIntoClientArea is to let you paint the NC area in your normal paint. So just do that dummy. * This doesn't transition across monitors. * This has a window style change I think is wrong. * I'm not sure the margins change is important. * The window style was _not_ important * Still getting a black xaml islands area (the HRGN) when we switch to high DPI * I don't know if this affects anything. * heyo this works. I'm not entirely sure why. But if we only update the titlebar drag region when that actually changes, it's a _lot_ smoother. I'm not super happy with the duplicated work in _UpdateDragRegion and OnSize, but checking this in in case I can't figure that out. * Add more comments and cleanup * Try making the button RightCustomContent * * Make the MinMaxClose's drag bar's min size the same as a caption button * Make the new tab button transparent, to see how that looks * Make sure the TabView doesn't push the MMC off the window * Create a TitlebarControl * The TitlebarControl is owned by the NCIW. It consists of a Content, DragBar, and MMCControl. * The App instatntiates a TabRowControl at runtime, and either places it in the UI (for tabs below titlebar) or hangs on to it, and gives it to the NCIW when the NCIW creates its UI. * When the NCIW is created, it creates a grid with two rows, one for the titlebar and one for the app content. * The MMCControl is only responsible for Min Max Close now, and is closer to the window implementation. * The drag bar takes up all the space from the right of the TabRow to the left of the MMC * Things that **DON'T** work: - When you add tabs, the drag bar doesn't update it's size. It only updates OnSize - The MMCControl's Min and Max buttons don't seem to work anymore. - They should probably just expose their OnMinimizeClick and OnMaximizeClick events for the Titlebar to handle minimizing and maximizing. - The drag bar is Magenta (#ff00ff) currently. - I'm not _sure_ we need a TabRowControl. We could probably get away with removing it from the UI tree, I was just being dumb before. * Fix the MMC buttons not working I forgot to plumb the window handle through * Make the titlebar less magenta * Resize the drag region as we add/remove tabs * Move the actual MMC handling to the TitlebarControl * Some PR nits, fix the titlebar painting on maximize * Put the TabRow in our XAML * Remove dead code in preparation for review * Horrifyingly try Gdi Plus as a solution, that is _wrong_ though * Revert "Horrifyingly try Gdi Plus as a solution, that is _wrong_ though" This reverts commit e038b5d9216c6710c2a7f81840d76f8130cd73b8. * This fixes the bottom border but breaks the titlebar painting * Fix the NC bottom border * A bunch of the more minor PR nits * Add a MinimizeClick event to the MMCControl This works for Minimize. This is what I wanted to do originally. * Add events for _all_ of the buttons, not just the Minimize btn * Change hoe setting the titlebar content works Now the app triggers a callcack on the host to set the content, instead of the host querying the app. * Move the tab row to the bottom of it's available space * Fix the theme reloading * PR nits from @miniksa * Update src/cascadia/WindowsTerminal/NonClientIslandWindow.cpp Co-Authored-By: Michael Niksa <miniksa@microsoft.com> * This needed to be fixed, was missed in other PR nits * runformat wait _what_ * Does this fix the CI build?
2019-07-19 00:21:33 +02:00
<SubType>Code</SubType>
</Midl>
Make tab header a custom control (#8227) This PR makes the Header of TabViewItem a custom user control. ## Validation Steps Performed Manual testing Closes #8201
2020-11-20 18:16:38 +01:00
<Midl Include="TabHeaderControl.idl">
<DependentUpon>TabHeaderControl.xaml</DependentUpon>
<SubType>Code</SubType>
</Midl>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<Midl Include="HighlightedTextControl.idl">
<DependentUpon>HighlightedTextControl.xaml</DependentUpon>
<SubType>Code</SubType>
</Midl>
<Midl Include="HighlightedText.idl" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="ColorPickupFlyout.idl">
<DependentUpon>ColorPickupFlyout.xaml</DependentUpon>
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
<SubType>Code</SubType>
</Midl>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="CommandPalette.idl">
<DependentUpon>CommandPalette.xaml</DependentUpon>
Add support for the Command Palette (#6635) ## Summary of the Pull Request ![command-palette-001](https://user-images.githubusercontent.com/18356694/85313480-b6dbef00-b47d-11ea-8a8f-a802d26c2f9b.gif) This adds a first iteration on the command palette. Notable missing features are: * Commandline mode: This will be a follow-up PR, following the merge of #6537 * nested and iterable commands: These will additionally be a follow-up PR. This is also additionally based off the addenda in #6532. This does not bind a key for the palette by default. That will be done when the above follow-ups are completed. ## References * #2046 - The original command palette thread * #5400 - This is the megathread for all command palette issues, which is tracking a bunch of additional follow up work * #5674 and #6532 - specs * #6537 - related ## PR Checklist * [x] Closes #2046 - incidentally also closes #6645 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - delaying this until it's more polished. ## Detailed Description of the Pull Request / Additional comments * There's a lot of code for autogenerating command names. That's all in `ActionArgs.cpp`, because each case is so _not_ boilerplate, unlike the rest of the code in `ActionArgs.h`. ## Validation Steps Performed * I've been playing with this for months. * Tests * Selfhost with the team
2020-06-26 22:38:02 +02:00
<SubType>Code</SubType>
</Midl>
Bold matching text in the command palette (#7977) * Created a ViewModel class in the Command Palette called FilteredCommand, aggregating the Command, the filter and the highlighted presentation of the command name * This ListView of the filtered commands is bound to the vector of FilteredCommands * Introduced HighlightedTextControl user control with HighlightedText view model * Added this control to the ListView Item's grid * Bound the FilteredCommand's highlighted command name to the user control ## Validation Steps Performed * UT for matching algorithm * Only manual tests * Searching in CommandLine, SwitchTab and Nested Command modes * Checking for bot matching an non matching filters * Dogfooding Closes #6646
2020-11-06 02:37:45 +01:00
<Midl Include="FilteredCommand.idl" />
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<Midl Include="EmptyStringVisibilityConverter.idl" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ========================= Misc Files ======================== -->
<ItemGroup>
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
<PRIResource Include="Resources\en-US\Resources.resw" />
<OCResourceDirectory Include="Resources" />
<None Include="packages.config" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ========================= Project References ======================== -->
<ItemGroup>
<!--
the packaging project won't recurse through our dependencies, you have to
make sure that if you add a cppwinrt dependency to any of these projects,
you also update all the consumers
-->
<ProjectReference Include="$(OpenConsoleDir)src\types\lib\types.vcxproj" />
Introduce a WinRT utils library and "checked resources" (#3350) This commit introduces a C++/WinRT utility library and moves ScopedResourceLoader into it. I decided to get uppity and introduce something I like to call "checked resources." The idea is that every resource reference from a library is knowable at compile time, and we should be able to statically ensure that all resources exist. This is a system that lets us immediately failfast (on launch) when a library makes a static reference to a resource that doesn't exist at runtime. It exposes two new (preprocessor) APIs: * `RS_(wchar_t)`: loads a localizable string resource by name. * `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended for loading images or passing static resource keys as parameters to functions that will look them up later. Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()` (which uses `USES_RESOURCE`), but can make sure we don't ship something that'll blow up at runtime. It works like this: **IN DEBUG MODE** - All resource names referenced through `USES_RESOURCE()` are emitted alongside their referencing filenames and line numbers into a static section of the binary. That section is named `.util$res$m`. - We emit two sentinel values into two different sections, `.util$res$a` and `.util$res$z`. - The linker sorts all sections alphabetically before crushing them together into the final binary. - When we first construct a library's scoped resource loader, we iterate over every resource reference between `$a` and `$z` and check residency. **IN RELEASE MODE** - All checked resource code is compiled out. Fixes #2146. Macros are the only way to do something this cool, incidentally. ## Validation Steps Performed Made references to a bunch of bad resources, tried to break it a lot. It looks like this when it fails: ### App.cpp ``` 36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels { 37 USES_RESOURCE(L"NoProfilesText"), 38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING") 39 }; ``` ``` WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll: FailFast(1) tid(1034) 8000FFFF Catastrophic failure Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent] ```
2019-11-01 23:47:05 +01:00
<ProjectReference Include="$(OpenConsoleDir)src\cascadia\WinRTUtils\WinRTUtils.vcxproj">
<Project>{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<!-- For whatever reason, we can't include the TerminalControl and
TerminalSettings projects' winmds via project references. So we'll have to
manually include the winmds as References below -->
</ItemGroup>
<PropertyGroup>
<!-- This is a hack to get the ARM64 CI build working. See
https://github.com/Microsoft/msbuild/issues/3746 - it looks like MsBuild
just has a bug in it.-->
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>Warning</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
<ItemGroup>
<!-- Manually add references to each of our dependent winmds. Mark them as
private=false and CopyLocalSatelliteAssemblies=false, so that we don't
Fix a bunch of spelling errors across the project (#4295) Generated by https://github.com/jsoref/spelling `f`; to maintain your repo, please consider `fchurn` I generally try to ignore upstream bits. I've accidentally included some items from the `deps/` directory. I expect someone will give me a list of items to drop, I'm happy to drop whole files/directories, or to split the PR into multiple items (E.g. comments/locals/public). Closes #4294
2020-02-10 21:40:01 +01:00
propagate them upwards (which can make referencing this project result in
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
duplicate type definitions)-->
<Reference Include="Microsoft.Terminal.TerminalConnection">
Remove all our path antics; force native projects to bin/, obj/ (#8062) This commit fixes our longstanding build artifact output issues and finally unifies all C++ project output into bin/ and obj/. In light of that, I've removed NoOutputRedirection. I've also updated WTU and U8U16Test to use our common build props and fixed any warnings/compilation errors that popped out. I validated this change by running repeated incremental builds after changing individual .cpp files in many of our C++/WinRT projects.
2020-10-27 23:00:41 +01:00
<HintPath>$(OpenConsoleCommonOutDir)TerminalConnection\Microsoft.Terminal.TerminalConnection.winmd</HintPath>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<IsWinMDFile>true</IsWinMDFile>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
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
<Reference Include="Microsoft.Terminal.Control">
<HintPath>$(OpenConsoleCommonOutDir)Microsoft.Terminal.Control\Microsoft.Terminal.Control.winmd</HintPath>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<IsWinMDFile>true</IsWinMDFile>
Add a keybinding option to Terminal to open the Settings UI (#8048) This commit iontroduces another `target` to the `openSettings` binding: `settingsUI`. It opens the settings UI introduced in the previous commit. Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Leon Liang <lelian@microsoft.com>
2020-12-11 22:34:57 +01:00
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
<Reference Include="Microsoft.Terminal.Settings.Editor">
<HintPath>$(OpenConsoleCommonOutDir)Microsoft.Terminal.Settings.Editor\Microsoft.Terminal.Settings.Editor.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
<Reference Include="Microsoft.Terminal.Settings.Model">
Remove all our path antics; force native projects to bin/, obj/ (#8062) This commit fixes our longstanding build artifact output issues and finally unifies all C++ project output into bin/ and obj/. In light of that, I've removed NoOutputRedirection. I've also updated WTU and U8U16Test to use our common build props and fixed any warnings/compilation errors that popped out. I validated this change by running repeated incremental builds after changing individual .cpp files in many of our C++/WinRT projects.
2020-10-27 23:00:41 +01:00
<HintPath>$(OpenConsoleCommonOutDir)Microsoft.Terminal.Settings.Model\Microsoft.Terminal.Settings.Model.winmd</HintPath>
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
<IsWinMDFile>true</IsWinMDFile>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
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
<Reference Include="Microsoft.Terminal.Core">
<HintPath>$(OpenConsoleCommonOutDir)TerminalCore\Microsoft.Terminal.Core.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
</Reference>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</ItemGroup>
<!-- ====================== Compiler & Linker Flags ===================== -->
<ItemDefinitionGroup>
<ClCompile>
<PrecompiledHeaderFile>pch.h</PrecompiledHeaderFile>
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
<AdditionalIncludeDirectories>..;%(AdditionalIncludeDirectories);</AdditionalIncludeDirectories>
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<!-- Manually disable unreachable code warning, because jconcpp has a ton of that. -->
<DisableSpecificWarnings>4702;%(DisableSpecificWarnings)</DisableSpecificWarnings>
</ClCompile>
<Link>
<AdditionalDependencies>WindowsApp.lib;shell32.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
<!-- ========================= Globals ======================== -->
<Import Project="$(OpenConsoleDir)src\cppwinrt.build.post.props" />
deps: upgrade CppWinRT to 2.0.200316.3, gsl to v2.1.0 (#4536) This commit upgrades C++/WinRT to 2.0.200316.3 and fixes a couple of the transitive dependency issues we had in the process. Because the latest version has better dependency resolution, we're able to properly depend on Microsoft.UI.Xaml and the Toolkit in TerminalApp and TerminalAppLib so we no longer need to manually include .dll and .pri files. Because of nebulous _other_ changes in dependency resolution, WindowsTerminalUniversal isn't picking up transitive .winmd dependencies from TerminalApp, and needs to include them as ProjectReferences directly. This was already happening transitively, so now it's explicit. I've also taken the time to upgrade GSL to v2.1.0, the last release before they removed span::at and blew up our world.
2020-03-23 18:15:24 +01:00
Update to Microsoft.UI.Xaml 2.5 "stable" (#8500) This commit moves us to the Xaml prerelease (201202003) that is equivalent to public stable release 2.5. Remember, we need to use prereleases for some silly reason.
2020-12-05 00:49:45 +01:00
<Import Project="..\..\..\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets" Condition="Exists('..\..\..\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets')" />
Update Win32 Toolkit (6.1.2) and VCRT Forwarders (1.0.4) (#8501) There's a handful of small changes in these updates: The Win32 Toolkit is now built with CFG (I think), and the VCRT forwarders are now the (second) non-RC version.
2020-12-10 02:30:00 +01:00
<Import Project="..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets" Condition="Exists('..\..\..\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
Update to Microsoft.UI.Xaml 2.5 "stable" (#8500) This commit moves us to the Xaml prerelease (201202003) that is equivalent to public stable release 2.5. Remember, we need to use prereleases for some silly reason.
2020-12-05 00:49:45 +01:00
<Error Condition="!Exists('$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(OpenConsoleDir)\packages\Microsoft.UI.Xaml.2.5.0-prerelease.201202003\build\native\Microsoft.UI.Xaml.targets'))" />
Update Win32 Toolkit (6.1.2) and VCRT Forwarders (1.0.4) (#8501) There's a handful of small changes in these updates: The Win32 Toolkit is now built with CFG (I think), and the VCRT forwarders are now the (second) non-RC version.
2020-12-10 02:30:00 +01:00
<Error Condition="!Exists('$(OpenConsoleDir)\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(OpenConsoleDir)\packages\Microsoft.Toolkit.Win32.UI.XamlApplication.6.1.2\build\native\Microsoft.Toolkit.Win32.UI.XamlApplication.targets'))" />
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
</Target>
deps: upgrade CppWinRT to 2.0.200316.3, gsl to v2.1.0 (#4536) This commit upgrades C++/WinRT to 2.0.200316.3 and fixes a couple of the transitive dependency issues we had in the process. Because the latest version has better dependency resolution, we're able to properly depend on Microsoft.UI.Xaml and the Toolkit in TerminalApp and TerminalAppLib so we no longer need to manually include .dll and .pri files. Because of nebulous _other_ changes in dependency resolution, WindowsTerminalUniversal isn't picking up transitive .winmd dependencies from TerminalApp, and needs to include them as ProjectReferences directly. This was already happening transitively, so now it's explicit. I've also taken the time to upgrade GSL to v2.1.0, the last release before they removed span::at and blew up our world.
2020-03-23 18:15:24 +01:00
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * Refactors TerminalApp into two projects: - TerminalAppLib, which builds a .lib, and includes all the code - TerminalApp, which builds a dll by linking the lib * Adds a TerminalApp.Unit.Tests project - Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation - includes the ability to test types with XAML content using an appxmanifest * Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR. ------------------------- These are some previous commit messages. They may be helpful to future readers. * Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042 * VS automatically did this for me * This is a dead end I tried including the idl-y things into the lib, but that way leads insanity If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets that ProjectReferences can have winmd's in them, so it won't be able to compile any types from the referenced projects. If you instead try to manually reference the types, you'll get duplicate types up the wazoo, which of course is insane, since we're referencing them the _one_ time * Yea just follow #1042 on github for status So current state: 1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and TerminalSettings, then mdmerge will complain about all the types from TerminalSettings being defined twice. In this magic scenario, the dependencies of TerminalControl are used directly for some reason: ``` 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd. 12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd. ``` 2. If you don't add a `Reference` TerminalControl, then it'll complain about being unable to find the type TitleChangedEventArgs, which is defined in TerminalControl. 3. If you don't add a `Reference` TerminalSettings, then it'll complain about being unable to find the type KeyChord and other types from TerminalSettings. In this scenario, it doesn't recurse on the other dependencies from TerminalControl for whatever reason. 4. If you instead try to add all 3 as a `ProjectReference`, then it'll complain about being unable to find TitleChangedEventArgs, as in 2. Presumably, it;ll have troubles with the other types too, as none of the 3 are actually included in the midlrt.rsp file. 5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration Microsoft.UI.Xaml.Markup.XamlApplication` 6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND MUX.Markup as a `Reference`, you'll get the same result as 3. * what if we just don't idl This seems to compile * This compiles but I broke the MUX resources look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that! * lets do this If I leave the MUX nuget out of the project, I'll get a compile error in App.xaml: ``` ...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls' ``` If I add it back to the project, it works * Some cleanup from the previous commit * This is busted again. Doing a clean build didn't work. A clean rebuild of the project, paired with some removal of dead code revealed a problem with what I have so far. TerminalAppLib depends on the generation of two headers, `AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the winrt types. They're needed to be able to compile the implementations. Presumably that's not getting generated by the lib project, because the dll project is the one to generate that file. So we need to move the idl's to the lib project. This created maddness, because of course the Duplicate Type thing. The solution to that is to actually mark the winrt DLLs that we're chaining up through us as ``` <Private>false</Private> <CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies> ``` This will prevent them from getting double-included. This still doesn't work however, since ``` app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp' error C3861: 'XamlMetaDataProvider': identifier not found ``` So we need to figure that out. The dll project is still generating the right header, so lets look there. * Move the xaml stuff to the lib This compiles, but when we launch, we fail to load the tabviewcontrol resources again. So that's not what you want. Why is it not included? * It works again! * Use the pri, xbf files from TerminalAppLib, not TerminalApp * Manually make TerminalApp include a reference to TerminalAppLib's TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the TerminalApp project (it's expecting it to have a winmd) * Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The dll doesn't do any codegen anymore. * Agressively clean up these files * Clean up unnecessary includes in the dll pch.h * This does NOT work. The WindowsxamlManager call crashes. I'm thinking it has to do with activation of winrt types from a dll. Email out to @Austin-Lamb to see if he can assist * This gets our cppwinrt types working, but xaml islands is still broken * Split the tests apart, so they aren't insane * These are the magic words to make xaml islands work * All this witchcraft is necessary to make XAML+MUX work right * Clean this up a bit and add comments * Create an enormous doc explaining this madness * Unsure how this got changed. * Trying to get the CI build to work again. This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false. However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference. * Update cppwinrt to the latest version - this fixes the MSBuild * I still need to re-add the KeyModifiers checks from TermControl. I think this update broke `operator&` for that enum. * There needs to be some cleanup obviously * The doc should be updated as well * Clean up changes from cppwinrt update * Try doing this, even though it seems wrong * Lets try this (press x to doubt) * Clean up vcxproj file, and remove appxmanifest change from previous commit * Update to the latest TAEF release, maybe that'll work * Let's try a prerelease version, shall we? * Add notes about TAEF package, comment out tests * Format the code * Hopefully fix the arm64 and x86 builds also a typo * Fix PR nits * Fix some bad merge conflicts * Some cleanup from the merge * Well I was close to getting the merge right * I believe this will fix CI * Apply suggestions from code review Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com> * These definitely need to be fixed * Try version detecting in the test IDK if this will build, I'm letting the CI try while I clean rebuild locally * Try blindly updating to the newest nuget version * Revert "Try blindly updating to the newest nuget version" This reverts commit b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * We're just going to see if these work in CI with this change * Comment the tests back out. Windows Server 2019 is 10.0.17763.557 * Remove the nuget package We don't need this package anymore now that we're hosting it * Okay this _was_ important
2019-07-15 21:27:56 +02:00
<!--
By default, the PRI file will contain resource paths beginning with the
project name. Since we enabled XBF embedding, this *also* includes App.xbf.
Well, App.xbf is hardcoded by the framework to be found at the resource ROOT.
To make that happen, we have to disable the prepending of the project name
to the App xaml files.
-->
<PropertyGroup>
<_GenerateProjectPriFileDependsOn>OpenConsolePlaceAppXbfAtRootOfResourceTree;$(_GenerateProjectPriFileDependsOn)</_GenerateProjectPriFileDependsOn>
</PropertyGroup>
<Target Name="OpenConsolePlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs">
<ItemGroup>
<_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" />
<PackagingOutputs Remove="@(_RelocatedAppXamlData)" />
<PackagingOutputs Include="@(_RelocatedAppXamlData)">
<TargetPath>%(Filename)%(Extension)</TargetPath>
</PackagingOutputs>
</ItemGroup>
</Target>
Move all wildcards into targets or expand them (#6406) Wildcards are not allowed in toplevel ItemGroups in vcxproj; they must be generated by targets. We mostly use wildcards for pulling in PRI files that are dumped on disk by the translation tool. We don't want to check those in, so we can't expand references to them. To that end, I've introduced a new target that will take a list of folders containing resw files and expand wildcards under them. All[1] other wildcards have been moved into their respective targets _or_ simply expanded. [1]: Nothing has complained about the resource wildcards in CascadiaResources.build.items, so I haven't exploded it yet. Fixes #6214.
2020-06-08 23:01:47 +02:00
<Import Project="$(SolutionDir)build\rules\CollectWildcardResources.targets" />
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
</Project>
Reference in a new issue Copy permalink