-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make ColorScheme a WinRT object #7238
Conversation
c60f366
to
dc958d4
Compare
UInt32 Foreground { get; }; | ||
UInt32 Background { get; }; | ||
UInt32 SelectionBackground { get; }; | ||
UInt32 CursorColor { get; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's not dig this hole deeper. Introduce a Color struct type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can specialize its conversion to/from til::color
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably should have just gone with Windows.UI.Color
- my bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated ColorScheme to use Windows.UI.Color. Should I go ahead and propagate that change to ICoreSettings
too? I'm already here.
dc958d4
to
d1a30bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay other than this one comment, I'm okay with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to remove a few more TerminalSettings references
I don't get it. All that 7a3ca00 did was rename some variables. The responsibility to apply a color scheme to an IControlSettings lies inside TerminalApp where TerminalSettings lives. You haven't done anything to break the dependency from colorscheme to terminal control (where IControlSettings now lives) |
At some point I had ColorScheme.idl referencing a TerminalSettings. That shouldn't be allowed. Making it reference an IControlSettings is better, but you're right, all of that logic should be moved to TermApp. I was thinking of this little change being a stepping stone to #885's last step (Move the new WinRT settings objects into TerminalSettings project). We don't need the separation until then, at which point I'll also move the similar logic over for Profile. TLDR: referencing IControlSettings > TerminalSettings |
I actually disagree that it’s better! Eventually, the interfaces for settings will become read-only and you will need to transition this code back to using a class type that has setters on it. Moving to the interface right now is going to be a roadblock for when you inevitably have to concentrate the logic in App. |
(cf #7219) |
07dfdb7
to
1fb018d
Compare
result[i] = _table[i]; | ||
} | ||
winrt::com_array<Color> result{ COLOR_TABLE_SIZE }; | ||
std::transform(_table.begin(), _table.end(), result.begin(), [](til::color c) -> Color { return c; }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is fine because a til::color is small enough to fit in a single register (or two registers), but it could be an expensive copy for any other struct. prefer const x&
unless otherwise okay
Summary of the Pull Request
ColorScheme is now a WinRT object in the TerminalApp project.
References
#7141 - ColorScheme is a settings object
#885 - this new settings object will be moved to a new TerminalSettingsModel project
PR Checklist
Detailed Description of the Pull Request / Additional comments
All of the JSON stuff can't be exposed via the idl. So the plan here is that we'll have the TerminalSettingsModel project handle all of the serialization when it's moved over. These functions will be exposed off of the
implementation
namespace, not projected namespace.Validation Steps Performed