-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Update ColorScheme with Json Serializer and color table API #7609
Conversation
#define GETSET_COLORTABLEPROPERTY(name) \ | ||
public: \ | ||
winrt::Windows::UI::Color name() const noexcept { return _table[##name##Index]; } \ | ||
void name(const winrt::Windows::UI::Color& value) noexcept { _table[##name##Index] = value; } |
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.
do we need an observable/notifier here?
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.
Maybe? I'll hold off on that for when we get the UI hooked up.
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.
gosh i love this jsonutils stuff. good work!
// This should only be used for color types where there's no logic in the | ||
// getter/setter beyond just accessing/updating the value. | ||
// This takes advantage of til::color | ||
#define GETSET_COLORPROPERTY(name, ...) \ | ||
public: \ | ||
winrt::Windows::UI::Color name() const noexcept { return _##name; } \ | ||
void name(const winrt::Windows::UI::Color& value) noexcept { _##name = value; } \ | ||
\ | ||
private: \ |
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.
is this really a generic-enough helper that it belongs in utils
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.
Eh? 🤷♂️ Yes, because WinUI::Color should be how we expose colors across layers, and we want to leverage til::color as much as we can? Only 50% confident here haha
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.
I think that some of this C++/winrt stuff might magically take care of it for us ...
so what happens if you just use GETSET_PROPERTY(til::color, Foreground)
or whatever?
There's a trick to c++/winrt, and that trick is that your implementation methods don't actually need to match your signatures at all ;)
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, I think that this won't automatically work because the type it's looking for is actually a struct_Windows_UI_Color
and the detach_from
helper does not allow for type coercion.
Co-authored-by: Dustin L. Howett <[email protected]>
// This should only be used for color types where there's no logic in the | ||
// getter/setter beyond just accessing/updating the value. | ||
// This takes advantage of til::color | ||
#define GETSET_COLORPROPERTY(name, ...) \ | ||
public: \ | ||
winrt::Windows::UI::Color name() const noexcept { return _##name; } \ | ||
void name(const winrt::Windows::UI::Color& value) noexcept { _##name = value; } \ | ||
\ | ||
private: \ |
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.
I think that some of this C++/winrt stuff might magically take care of it for us ...
so what happens if you just use GETSET_PROPERTY(til::color, Foreground)
or whatever?
There's a trick to c++/winrt, and that trick is that your implementation methods don't actually need to match your signatures at all ;)
@@ -293,19 +293,39 @@ namespace TerminalAppUnitTests | |||
// versions. | |||
|
|||
template<typename TExpected, typename TJson> | |||
static void TryBasicType(TExpected&& expected, TJson&& json) | |||
static void TryBasicType(TExpected&& expected, TJson&& json, std::optional<std::string> overrideToJsonOutput = std::nullopt) |
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.
shouldn't this be an optional json::value? so you can specify {1}
or something?
then later you can use expectedJson[key] = override.value_or(jsonObject);
and simplify the code?
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.
Ah. I was trying to do that, but I messed up by making it a std::optional<TJson>
instead of std::optional<Json::Value>
. Derp!
// - json: an object which will be a serialization of a ColorScheme object. | ||
// Return Value: | ||
// <none> | ||
void ColorScheme::UpdateJson(Json::Value& json) |
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.
i 100% expected you to go a different direction with this and just .. make it a function called ToJson
that returned the json object.
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.
Is there ever a reason for us to call UpdateJson multiple times with different color schemes? (or profiles, etc.)?
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.
Ideally, I could name it LayerJson
with an out param because we're really just layering our values onto the Json. But I guess that isn't something we're doing yet, so yeah, renaming to ToJson
as you expected haha
I'm going to admin override this because it's failed on #7654 |
Add
ToJson()
to theConversionTrait
s in JsonUtils. This can be usedto serialize settings objects into JSON.
As a proof of concept,
ToJson
andUpdateJson
were added toColorScheme
.Getters and setters for members and colors in the color table were added
and polished.
References
#1564 - Settings UI
ColorScheme
is a particularly easy example of serialization because ithas no fallback.
Added a few tests for JSON serializers.