Replace TerminalSettings runtimeclasses with interfaces only

[DHowett-MSFT]

TerminalSettings.dll exists because it is difficult to coerce the C++/WinRT build infrastructure to produce a type library and a set of headers without either statically linking (which rolls up the generated types into the consuming project) or dynamically linking (which forces us to put a DLL on disk).

I posit that the ideal representation of settings is the ICoreSettings and IControlSettings interfaces only. No classes need to be implemented in TerminalSettings.dll, because all they'd do is ferry data back and forth.

By dropping the classes and switching to the interfaces, we can remove the setters from the interfaces, and remove the runtime classes completely. Cascadia (or TerminalApp::<something>) can implement ICoreSettings and IControlSettings as views over existing profile data.

This will reduce both the number of runtime hops required for loading and saving settings and the number of code authoring hops required for adding new settings.

Approach

• Introduce/Move TerminalApp bridge #7139: Introduce/Move TerminalApp bridge
  • Move TerminalSettings::TerminalSettings to TerminalApp::TerminalSettings
• Move TerminalSettings interfaces #7140: Move TerminalSettings interfaces
  • Move TerminalSettings::ICoreSettings to TerminalControl project
  • Move TerminalSettings::IControlSettings to TerminalControl project
• Transform TerminalApp settings objects into WinRT objects #7141: Transform TerminalApp settings objects into WinRT objects
  • Profile
  • ColorScheme
  • GlobalSettings
  • Keybindings (this may be moved out to be its own PR)
• Move the new WinRT settings objects into TerminalSettings project
  • I'll close the scenario when this is complete

[zadjii-msft]

So that's what I tried initially. However, the TerminalCore project is a non-cppwinrt static lib. This was done to avoid having dll hops between TerminalCore and TerminalControl, which I believed would be frequent. Because TerminalCore wasn't a cppwinrt project, it couldn't generate a winmd/header pair for the idl.

Trying to make it a cppwinrt static library also introduced it's own insanity of build errors, where sometimes the winmd would be double included, or not included at all.

You also can't have a cppwinrt project that only has interface definitions without defining at least one type. I don't know if that was resolved in cppwinrt 2.0 or not. I tried this initially by making a TerminalSettings project that only included two idl files, but somewhere up the tree, msbuild was not be happy about the fact that the project didn't generate a dll (since it had no code, it didn't build a dll).

[DHowett-MSFT]

Indeed. I'll mark this help-wanted; I know that it's possible to have a project that only produces a type library, we just might need to dig deep on build system arcana.

[DHowett-MSFT]

Notes: I think it's okay that TerminalCore wouldn't be a C++/WinRT project. Since it does live on the "fully C++" side of the world, it wouldn't be unreasonable for it to use wil::com_ptr over the raw interface types in the ::ABI namespace that MIDL generates. It might even be preferable... the annoying thing is unpacking HSTRINGs, but even that really isn't all that bad.

It can also become a C++/WinRT consumer very easily. It's significantly cheaper than authoring components, and it is the recommended way to consume all WinRT APIs in all C++ code.

[dlong11]

@zadjii-msft - First I am no expert on this and I am just starting to read up on WinRT. Plus - I don't think I 100% understand the issue, but the discussion helps me learn. So please ignore if this isn't helpful.

You also can't have a cppwinrt project that only has interface definitions without defining at least one type. I don't know if that was resolved in cppwinrt 2.0 or not. I tried this initially by making a TerminalSettings project that only included two idl files, but somewhere up the tree, msbuild was not be happy about the fact that the project didn't generate a dll (since it had no code, it didn't build a dll).

Instead of doing a project for this, could you use the command line and build step? Use midl.exe and compile the idl files then combine them. Then use cppwinrt.exe to generate the headers.

If I understand the issue correctly it appears this will work.

Docs that I have been reading on this.
midl command line
cppwinrt example

[zadjii-msft]

That's certainly an idea. I'd be wary to make sure that the build artifacts are included correctly in all the consuming projects, but it's certainly something worth trying.

[simonbuchan]

Huh, I was assuming TerminalSettings was a WinRT dll so you could eventually have your own app hosting TerminalControl load the user's default settings using the same logic and hand them off to as much of the other packages as you were using...

Basically, would it make sense to just move the parsing code into TerminalSettings and actually have a .dll on disk?

[zadjii-msft]

I certainly considered that. I was thinking about something like Visual Studio, which could host a version of the control (or something using the core at least). They however probably want to use their own settings serialization and settings structure. They probably don't have any notion of profiles or anything like that, and they probably want to store the settings as XML. So, I wanted TerminalSettings to be application-independent, so any app could implement settings however they like, so long as they pass a common settings structure to the terminal itself.

[DHowett-MSFT]

Note to whoever follows up:

terminal/src/cascadia/TerminalSettings/TerminalSettings.cpp

Lines 125 to 129 in 5119ed1

	if (!SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, &systemRowsToScroll, 0))
	{
	systemRowsToScroll = 4;
	}
	return systemRowsToScroll;

TerminalSettings is no longer a "dumb data carrier", and this logic will need to be moved to wherever it ends up living.

(/cc @hannesne)

[ghost]

🎉This issue was addressed in #7667, which has now been successfully released as Windows Terminal Preview v1.5.3142.0.:tada:

Handy links:

• Release Notes
• Store Download