Separate runtime TerminalSettings from profile-TerminalSettings#8602
Conversation
|
It's weird -- I'm running a build of this with default settings (like, I cleared my app settings) and all my colors are black. Indicates the color table is all 0s. |
| #pragma once | ||
|
|
||
| #include "TerminalSettings.g.h" | ||
| #include "../TerminalSettingsModel/IInheritable.h" |
There was a problem hiding this comment.
(This is a much larger discussion that doesn't have to be implemented as a part of this PR. So really I'm thinking out loud.)
I'm wondering if we should move TerminalSettings over to TerminalSettingsModel. Hear me out:
- if we're making
TerminalSettingsIInheritable, might as well moveTerminalSettingsover to TSM. It's a bit weird for us to grab this random file from a separate project, right? haha - With regards to creating a TermControl preview in Settings UI...
- I hit a problem today. TSE cannot depend on TermApp because that'd create a circular dependency (TermApp <--> TSE). So I tried making it so that TSE builds a
TerminalSettingsby firing an event to TermApp, but then TermApp would need to somehow get the synthesizedTerminalSettingsobject down to the profile page and update on each change. HavingTerminalSettingsbe its own project or a part of TSM makes it it so much easier to constructTerminalSettingsand just have one readily available for a TermControl preview.
- I hit a problem today. TSE cannot depend on TermApp because that'd create a circular dependency (TermApp <--> TSE). So I tried making it so that TSE builds a
What do you think?
CC @DHowett for thoughts on this matter too. I might just be approaching the two things above completely wrong haha
There was a problem hiding this comment.
You might have a point here (but it should probably be a follow up)
There was a problem hiding this comment.
Bumping this thread for @DHowett because this is important for the terminal preview in SUI.
Fixed with latest push - I did need to implement a separate macro to implement an array setting though (if you try |
|
@msftbot wait 8 hours before merging this |
|
Hello @zadjii-msft! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
zadjii-msft
left a comment
There was a problem hiding this comment.
You know, I was about to sign off on this, but now I'm all worried about the copying of the array, and I think it's best if we let Dustin or Michael be the second on it
| #pragma once | ||
|
|
||
| #include "TerminalSettings.g.h" | ||
| #include "../TerminalSettingsModel/IInheritable.h" |
There was a problem hiding this comment.
You might have a point here (but it should probably be a follow up)
| \ | ||
| private: \ | ||
| std::optional<std::array<type, size>> _##name{ std::nullopt }; \ | ||
| std::optional<std::array<type, size>> _get##name##Impl() const \ |
There was a problem hiding this comment.
I wanna make sure Dustin takes a look at the template magic going on in this macro. An optional<array<T>> seems to make sense to me, but there might be weird template quirks I'm missing.
| /*iterate through parents to find a value*/ \ | ||
| for (auto parent : _parents) \ | ||
| { \ | ||
| if (auto val{ parent->_get##name##Impl() }) \ |
There was a problem hiding this comment.
Specifically this bit I'm worried about - are we returning a copy of the parent's result?
|
Touching to say we had a discussion about doing the array without copies. |
|
|
||
| namespace winrt::TerminalApp::implementation | ||
| { | ||
| static constexpr std::array<til::color, 16> campbellColorTable{ |
There was a problem hiding this comment.
Why can't we use the one from Utils? Is it because it's a filler-style method?
Maybe we can just expose a function that returns it directly... as a gsl::span.
There was a problem hiding this comment.
(Really don't love the duplication)
There was a problem hiding this comment.
Yeah I don't like the duplication either - will add a function to colorTable.hpp to expose the campbell color table
|
|
||
| namespace winrt::TerminalApp::implementation | ||
| { | ||
| static constexpr std::array<til::color, 16> campbellColorTable{ |
There was a problem hiding this comment.
(Really don't love the duplication)
| // issues: | ||
| // - converting span to array without brute force? | ||
| // - campbellColorTable conversion from color to uint32 | ||
| // - including colortable.cpp causes errors |
There was a problem hiding this comment.
we don't import cpp files, like... ever. 😄
| #include <DefaultSettings.h> | ||
| #include <conattrs.hpp> | ||
|
|
||
| using namespace Microsoft::Console::Utils; |
There was a problem hiding this comment.
ooh can you put out a PR that deletes this? we should never put a using in a header.
/cc @carlos-zamora @zadjii-msft 😄
There was a problem hiding this comment.
In fact, only the cpp file needs to know about colorTable.hpp and the using block, correct?
There was a problem hiding this comment.
Ah sorry my bad, made a PR to fix it
|
🎉 Handy links: |
Summary of the Pull Request
The TerminalSettings object we create from profiles no longer gets passed into the control, instead, a child of that object gets passed into the control. Any overrides the control makes to the settings then live in the child. So, when we do a settings reload, we simply update the child's parent and the overrides will remain.
PR Checklist
Validation Steps Performed
Manual testing