docs: Table formatting spec #889

mattrunyon · 2024-09-16T23:33:15Z

Fixes #792

Not sure who else might want to review this. This is a basic overview of how I see table formatting rules.

Things we might want to consider

Global rules for the table such as "format all columns as $x.xx"
Should we separate column and row formatting to separate props or just make separate dataclasses for them? One potential downside to multiple props is defining which takes precedence and do we still follow a stop_if_true if there's both a row and column color rule for example.

dsmmcken · 2024-09-18T14:50:15Z

plugins/ui/DESIGN.md

+        column_formatting=[
+            ui.table_formatting.COLOR("X", "RED"),
+            ui.table_formatting.COLOR("Y", "BLUE", where="Y % 2 == 0"),
+            ui.table_formatting.NUMBER_FORMAT("Y", format="0.00"),
+            ui.table_formatting.DATABAR("Z", value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED")
+        ],
+        row_formatting=[
+            ui.table_formatting.COLOR(where="X > 5", color="GREEN")
+        ]


One downside I see to splitting like this is the lack of control between interleaving the order of column and row formatting.

Doing something that is:
row rule
column rule
row rule

would not be possible

Yep. I noted in the PR body we might want to just have formatting instead. Also makes it clear what the applied order is

If separate, I think column beats row in terms of precedence.

I agree that splitting this up causes precedence ambiguity.

I might think that row beats column. e.g. make the whole row red because something bad is happening.

If separate I'd lean row beats column. A row is more specific on an individual basis than a column (ignoring all the filters and groups in this case and just thinking about what would more reasonably win if a single row and single column were highlighted). Although the differing opinions here may be a sign they should be combined. Might be tricky and confusing for a user to remember.

I would lean column beats row. You might make the whole row shaded yellow or whatever because something seems stale; but you don't want to eliminate the formatting that you would have otherwise applied to your "BUY/SELL" column.

I'm working on a revised spec that proposes combining into a single argument so there's no ambiguity or desire for column over row or row over column

dsmmcken · 2024-09-18T14:51:53Z

plugins/ui/DESIGN.md

+
+##### ui.table Formatting Rule Types
+
+There are 3 main types of formatting rules: those which affect basic visual aspects (color, font, etc.), those which affect the display value (number formatting, etc.), and those which affect the cell rendering mode (data bars, buttons, etc.). Multiple different visual rules can be applied at the same time, but only one display value rule and one cell rendering mode rule can be applied at a time. It doesn't make sense to have a cell that is both a data bar and a button, for example. If a rule is applied conditionally, multiple display or cell rendering rules should be allowed to be applied in a column.


Would need clear error message states for violating these rules.

I don't know if it would be possible for the user to violate these. If they did things would still work, but it would just apply the last (or stop after the first) rule that is true

dsmmcken · 2024-09-18T14:53:05Z

Maybe charles/chip/raffi might have good insights on things to cover.

cpwright · 2024-09-19T01:58:13Z

plugins/ui/DESIGN.md

+        column_formatting=[
+            ui.table_formatting.COLOR("X", "RED"),
+            ui.table_formatting.COLOR("Y", "BLUE", where="Y % 2 == 0"),
+            ui.table_formatting.NUMBER_FORMAT("Y", format="0.00"),
+            ui.table_formatting.DATABAR("Z", value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED")
+        ],
+        row_formatting=[
+            ui.table_formatting.COLOR(where="X > 5", color="GREEN")
+        ]


If separate, I think column beats row in terms of precedence.

cpwright · 2024-09-19T01:58:37Z

plugins/ui/DESIGN.md

+
+##### ui.table Row Formatting Rules
+
+Row formatting rules apply to entire rows. Only visual rules can be applied to rows. Row formatting rules should have an `where` field which is a conditional expression that determines if the rule should be applied. This expression will be applied as a custom column (which is applied with `update_view`) to the table and may reference columns or use the query language if needed. The conditional is required for row formatting rules because otherwise they would apply to every row in the table.


why does row have an update_view, but not a column?

Column rules would optionally have a where applied the same way. I think for rows we should require a where as otherwise the entire table would be formatted.

It might make sense to have certain format types that apply to the whole table though. Something like format all numeric columns as currency.

dsmmcken · 2024-09-23T19:48:33Z

How much of the existing formatting is this using vs us generating our own column?

How does the multiple queries targeting the same column combine?

mattrunyon · 2024-09-23T19:54:21Z

How much of the existing formatting is this using vs us generating our own column?

How does the multiple queries targeting the same column combine?

This would use none of our existing formatting code in the engine.

Each where clause would be applied as a separate custom column. We could combine into a single custom column that returns an int representing which rule was true. But the benefit might be negligible until you get into hundreds or thousands of rules on a table.

mattrunyon · 2024-09-23T19:54:47Z

@chipkent @devonpallison @rbasralian You might be interested in looking at this

mofojed

I like to see an example with stop_if_true usage, and also would like to see the option of having it as just one formatting with data classes for column vs row formatting

mofojed · 2024-09-30T15:07:53Z

plugins/ui/DESIGN.md

+
+Outside of these 2 properties, it is up to the Dataclass to identify what kind of formatting it is and up to the web to apply that formatting. We should likely use a field like `__format_type` that is part of each Dataclass as a key for identifying formatting rules.
+
+On the client, formatting rules should be applied in the order they are defined in the list. This means that if a rule is defined later in the list, it will take precedence over a rule defined earlier in the list. There should be a `stop_if_true` or equivalent property which would not apply any further formatting rules of the same type (e.g. background color) once a matching rule has been applied. This should make it possible to still apply different formatting types even if `stop_if_true` is `True`.


Example of stop_if_true usage?

My initial thoughts are that these 2 would be equivalent. You could apply the stop_if_true flag to individual rules like this.

formatting=[ ColumnColor('X', 'red', where='X % 3 == 0'), ColumnColor('X', 'yellow', where='X % 5 == 0'), ColumnColor('X', 'green', where='X % 15 == 0') ] formatting=[ ColumnColor('X', 'green', where='X % 15 == 0', stop_if_true=True) ColumnColor('X', 'red', where='X % 3 == 0'), ColumnColor('X', 'yellow', where='X % 5 == 0'), ]

One thing to note is I believe the Excel behavior is to apply all rules in order and they have a checkbox in the GUI when applying rules for "stop if true". Google Sheets stops at the first rule and is not configurable it seems.

Not sure if we have a preference on either behavior. I think the Google Sheets behavior can achieve the same things as Excel, but it is a little simpler for defining rules. First rule gets priority and that's it.

I think we would want to have the priority system per rule type which is a bit different from Sheets and Excel since you define the entire format (color, font color, font style, etc.) in 1 rule

Thinking through stop_if_true has pointed out some rough UI edges to consider.

Say you have a row that you want to format with a particular background color, font color, font, and whatever else. You end up with code that looks like:

formatting=[ ColumnColor('X', 'green', where='X % 15 == 0', stop_if_true=True), ColumnFont('X', 'arial', where='X % 15 == 0', stop_if_true=True), ColumnFontColor('X', 'blue', where='X % 15 == 0', stop_if_true=True) ... ]

This feels very repetitive because all of the related items for a cell repeat where and stop_if_true. Maybe what is here is good enough, but a few minutes should be spent considering this type of case.

mattrunyon · 2024-09-30T20:17:12Z

Something else I've thought about is how can we/should we support a format that includes multiple rules with 1 condition. Basically something like this Format(col="X", formats=[Color('red'), Value('0.00%')], where="X > 5"). Not sure what a better keyword than formats would be there

chipkent · 2024-09-30T20:25:02Z

plugins/ui/DESIGN.md

+
+Outside of these 2 properties, it is up to the Dataclass to identify what kind of formatting it is and up to the web to apply that formatting. We should likely use a field like `__format_type` that is part of each Dataclass as a key for identifying formatting rules.
+
+On the client, formatting rules should be applied in the order they are defined in the list. This means that if a rule is defined later in the list, it will take precedence over a rule defined earlier in the list. There should be a `stop_if_true` or equivalent property which would not apply any further formatting rules of the same type (e.g. background color) once a matching rule has been applied. This should make it possible to still apply different formatting types even if `stop_if_true` is `True`.


Thinking through stop_if_true has pointed out some rough UI edges to consider.

Say you have a row that you want to format with a particular background color, font color, font, and whatever else. You end up with code that looks like:

formatting=[ ColumnColor('X', 'green', where='X % 15 == 0', stop_if_true=True), ColumnFont('X', 'arial', where='X % 15 == 0', stop_if_true=True), ColumnFontColor('X', 'blue', where='X % 15 == 0', stop_if_true=True) ... ]

This feels very repetitive because all of the related items for a cell repeat where and stop_if_true. Maybe what is here is good enough, but a few minutes should be spent considering this type of case.

chipkent · 2024-09-30T20:25:26Z

plugins/ui/DESIGN.md

+The formatting rules should have 2 main properties:
+
+1. The formatting to apply.
+2. An optional conditional expression that will determine if the formatting should be applied.


Confirming that the conditional can be on columns that are not the column being formatted.

Yes the conditional will be applied as a custom column (uses update_view in the engine). So any expression works as long as it is a boolean result

chipkent · 2024-09-30T20:28:04Z

plugins/ui/DESIGN.md

+        column_formatting=[
+            ui.table_formatting.COLOR("X", "RED"),
+            ui.table_formatting.COLOR("Y", "BLUE", where="Y % 2 == 0"),
+            ui.table_formatting.NUMBER_FORMAT("Y", format="0.00"),
+            ui.table_formatting.DATABAR("Z", value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED")
+        ],
+        row_formatting=[
+            ui.table_formatting.COLOR(where="X > 5", color="GREEN")
+        ]


I agree that splitting this up causes precedence ambiguity.

chipkent · 2024-09-30T20:31:31Z

plugins/ui/DESIGN.md

+        column_formatting=[
+            ui.table_formatting.COLOR("X", "RED"),
+            ui.table_formatting.COLOR("Y", "BLUE", where="Y % 2 == 0"),
+            ui.table_formatting.NUMBER_FORMAT("Y", format="0.00"),
+            ui.table_formatting.DATABAR("Z", value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED")
+        ],
+        row_formatting=[
+            ui.table_formatting.COLOR(where="X > 5", color="GREEN")
+        ]


I might think that row beats column. e.g. make the whole row red because something bad is happening.

chipkent · 2024-09-30T20:34:05Z

plugins/ui/DESIGN.md

+2. Display Value (not applicable to rows)
+   - Number Formatting
+   - Date Formatting
+   - DateTime Formatting
+   - String Formatting


A user may want to apply a particular display value format (DVF) to all columns of a type. Does it make sense to support this, or would that feature not be used enough?

chipkent · 2024-09-30T20:34:59Z

plugins/ui/DESIGN.md

+1. Visual
+   - Background Color
+   - Font
+   - Font Color
+   - Font Size
+   - Text Alignment


As noted in the comment above, users may want to set multiple visual things at once.

chipkent · 2024-09-30T20:36:54Z

plugins/ui/DESIGN.md

+
+##### ui.table Column Formatting Rules
+
+Column formatting rules apply to specific columns. All column formatting rules should have a `column` field which is the column the rule applies to. We could optionally support `columns` (or just a `columns` prop which handles both cases) which would allow for a list of columns that the rule applies to.


The python table API supports one or more columns for most cases. It would feel natural to have that here as well. Variable naming should be consistent with what the table API is doing.

mattrunyon · 2024-10-02T18:47:15Z

Updated to include 3 new options for a single format prop. Of the options, I like 2 and 3 the best. I don't have a strong opinion between those 2

I also removed the stop_if_true. I think we could just say first matching rule for a type applies or last matching rule takes precedence. Unless there is some case I'm missing where stop_if_true is the only way instead of just ordering the rules by precedence.

chipkent · 2024-10-02T19:34:34Z

plugins/ui/DESIGN.md

@@ -2415,6 +2415,117 @@ ui_table.sort(
 | `by`        | `str \| Sequence[str]`                                       | The column(s) to sort by. May be a single column name, or a list of column names.                           |
 | `direction` | `TableSortDirection \| Sequence[TableSortDirection] \| None` | The sort direction(s) to use. If provided, that must match up with the columns provided. Defaults to "ASC". |

+##### ui.table Formatting Rules
+
+Tables can be formatted via the `format` prop and a variety of Dataclasses representing different formatting options. We choose to use Dataclasses as effectively a more strict dictionary. This allows for better type checking and easier to understand code.


What is the format prop?

Just a general name for the formatting arg on ui.table. Instead of having a column_formatting and row_formatting I'm proposing just a format or formatting arg instead

chipkent · 2024-10-02T19:42:21Z

plugins/ui/DESIGN.md

+
+With any of the options we could support some method of applying value formatting to all columns that support it. We could have an argument such as `all_columns=True` that would apply the rule to all columns that support it. This would be useful for number formatting, date formatting, etc.
+
+We could also support regex (or just wildcards) in the `cols` field to apply the rule to multiple columns at once. This could be useful if a user wanted to format all columns that end in percent as a percentage. Something like `FORMAT(cols=".*Percent", format="0.00%")`


We may want to support both regex and wildcards. Regex would hit the higher end devs that want specific control, and simple wildcards would hit the lower end users that have zero idea what a regex is but can handle simple wildcards.

If we support wildcards, possibly you don't need all_columns=True and could just use cols="*". That raises the question of if regex/wildards apply to all columns or just columns with matching types. I'm not sure which is least confusing. If it applies to all columns, there could be an only_supported_types=True option.

We would need some way to differentiate regex from wildcards. Probably just have users use r"/.*/" for regex strings and if there's no leading / then it's not regex.

True we could just support cols="*". I think initially most formatting options can apply to all columns (color, font color, etc.). The main thing that can't is the value formatting. If we have that under a single keyword in the dataclass, then we could assume it applies to all supported column types if there's columns w/ regex/wildcard. Maybe we want to warn if there's explicit column names only and the format doesn't apply to one of the explicitly listed columns.

chipkent · 2024-10-02T19:44:48Z

plugins/ui/DESIGN.md

+        ui.table_formatting.COLUMN_FORMAT(cols="X", color="RED"),
+        ui.table_formatting.COLUMN_FORMAT(cols="Y", color="BLUE", where="Y % 2 == 0"),
+        ui.table_formatting.COLUMN_FORMAT(cols="Y", format="0.00"),
+        ui.table_formatting.COLUMN_FORMAT(cols=["A", "B"], color="PURPLE", format="0.00%", where="A > 5"),
+        ui.table_formatting.COLUMN_FORMAT(cols="Z", format=ui.table_formatting.DATABAR(value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED"),
+        ui.table_formatting.ROW_FORMAT(where="X > 5", color="GREEN")


Is this really what you meant by Option 3, or did you have something like the following in mind?

Suggested change

ui.table_formatting.COLUMN_FORMAT(cols="X", color="RED"),

ui.table_formatting.COLUMN_FORMAT(cols="Y", color="BLUE", where="Y % 2 == 0"),

ui.table_formatting.COLUMN_FORMAT(cols="Y", format="0.00"),

ui.table_formatting.COLUMN_FORMAT(cols=["A", "B"], color="PURPLE", format="0.00%", where="A > 5"),

ui.table_formatting.COLUMN_FORMAT(cols="Z", format=ui.table_formatting.DATABAR(value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED"),

ui.table_formatting.ROW_FORMAT(where="X > 5", color="GREEN")

ui.table_formatting.FORMAT(cols="X", color="RED"),

ui.table_formatting.FORMAT(cols="Y", color="BLUE", where="Y % 2 == 0"),

ui.table_formatting.FORMAT(cols="Y", format="0.00"),

ui.table_formatting.FORMAT(cols=["A", "B"], color="PURPLE", format="0.00%", where="A > 5"),

ui.table_formatting.FORMAT(cols="Z", format=ui.table_formatting.DATABAR(value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED"),

ui.table_formatting.FORMAT(where="X > 5", color="GREEN")

Oops yes I copy/pasted and forgot to update that

chipkent · 2024-10-02T19:50:12Z

plugins/ui/DESIGN.md

+Option 1 ends up being more verbose (and causes code duplication) if you have multiple rules with the same condition. It also ends up with more potential imports for multiple rules if we recommend users import the dataclasses like `from deephaven.ui.table_formatting import COLOR, NUMBER_FORMAT, DATABAR`
+
+Option 2 is more concise and allows for multiple rules with the same condition without repeating. Two dataclasses is easier for a user to distinguish between the 2 rule types. Only 1 or 2 imports needed.
+
+Option 3 is more concise and allows for multiple rules with the same condition without repeating. One dataclass is easier for a user to understand that the rules are the same type. Only 1 import needed.


Are we trying to decide between the 3 options and just implementing one, or are we planning to implement all 3 so that the user has options on which to use?

If I had to pick one, I'd go with option 2, but I'm not necessarily against supporting all 3.

I think pick 1 and if there's enough reason to support other then we can implement that in the future. Just giving multiple syntax options to show what the syntax might look like

If I was designing this from scratch, I like option 3, because conceptually if I wanted to switch from (using existing terminology) a format_row_where to a format_column_where just adding on a column is much nicer that having to change the whole method when the only real difference is the column.
But, I recognize that 2 is closest to what we have now, and would be good to bridge the gap and allow a little more specification for those who want it.
So ideally we'd do both 2 and 3 in my opinion to start.

I think it would be fairly easy to support 2 and 3 without duplication on our end. If I'm reading correctly, dataclasses can use inheritance. So we'd basically implement 3 (1 dataclass w/ all fields) and then add thin dataclasses on top for column/row. The column dataclass would just mandate the cols field and inherit everything else from the base

Supporting all 3 is feasible I think if that's desired. We could do some mapping into the corresponding column/row/general structure.

My main gripe with the individual rules as dataclasses is it adds a lot of potential imports someone would have to add. I think we will want dataclasses for more complex value formatting rules like databars, but for something like color it might be a little annoying

dsmmcken · 2024-10-04T19:31:50Z

plugins/ui/DESIGN.md

+t3 = ui.table(
+    t,
+    format=[
+        ui.table_formatting.FORMAT(cols="X", color="RED"),


I would explore a shorter import, ui.table.format would be nice if we can.

dsmmcken · 2024-10-04T19:34:47Z

plugins/ui/DESIGN.md

+        ui.table_formatting.FORMAT(cols="Y", color="BLUE", where="Y % 2 == 0"),
+        ui.table_formatting.FORMAT(cols="Y", format="0.00"),
+        ui.table_formatting.FORMAT(cols=["A", "B"], color="PURPLE", format="0.00%", where="A > 5"),
+        ui.table_formatting.FORMAT(cols="Z", format=ui.table_formatting.DATABAR(value_col="Z", min=0, max=100, positive_color="GREEN", negative_color="RED"),


Having both format="0.00%" and format=ui.table_formatting.DATABAR seems confusing and also prevents setting a format on the databar.

Would it make sense to accept databar=ui.table.format.databar or kind=databar... kind=button... or something?

mattrunyon · 2024-10-14T22:46:14Z

Cleaned up design doc to reflect the preferred choice for formatting (Option 3 - single format dataclass w/ kwargs)

Table formatting spec

6ca66ae

mattrunyon requested review from dsmmcken and mofojed September 16, 2024 23:33

mattrunyon self-assigned this Sep 16, 2024

mattrunyon changed the title ~~Table formatting spec~~ docs: Table formatting spec Sep 16, 2024

dsmmcken reviewed Sep 18, 2024

View reviewed changes

dsmmcken requested a review from jnumainville September 18, 2024 14:52

cpwright reviewed Sep 19, 2024

View reviewed changes

Update column formatting where clause

07a38c1

mofojed reviewed Sep 30, 2024

View reviewed changes

chipkent reviewed Sep 30, 2024

View reviewed changes

Update spec to single prop options

c54ca31

mattrunyon requested review from dsmmcken, chipkent, cpwright and mofojed October 2, 2024 18:46

chipkent reviewed Oct 2, 2024

View reviewed changes

Fix syntax of option 3

b79967b

dsmmcken reviewed Oct 4, 2024

View reviewed changes

mattrunyon added 2 commits October 14, 2024 17:18

Merge branch 'main' into table-formatting-spec

8760b87

Clean up design doc for the preferred option

ed5704a

mattrunyon requested review from dsmmcken and chipkent October 14, 2024 22:39

dsmmcken approved these changes Oct 15, 2024

View reviewed changes

mattrunyon merged commit f79224a into deephaven:main Oct 16, 2024
16 checks passed

mattrunyon deleted the table-formatting-spec branch October 16, 2024 20:21


		##### ui.table Formatting Rule Types

		There are 3 main types of formatting rules: those which affect basic visual aspects (color, font, etc.), those which affect the display value (number formatting, etc.), and those which affect the cell rendering mode (data bars, buttons, etc.). Multiple different visual rules can be applied at the same time, but only one display value rule and one cell rendering mode rule can be applied at a time. It doesn't make sense to have a cell that is both a data bar and a button, for example. If a rule is applied conditionally, multiple display or cell rendering rules should be allowed to be applied in a column.


		##### ui.table Row Formatting Rules

		Row formatting rules apply to entire rows. Only visual rules can be applied to rows. Row formatting rules should have an `where` field which is a conditional expression that determines if the rule should be applied. This expression will be applied as a custom column (which is applied with `update_view`) to the table and may reference columns or use the query language if needed. The conditional is required for row formatting rules because otherwise they would apply to every row in the table.


		Outside of these 2 properties, it is up to the Dataclass to identify what kind of formatting it is and up to the web to apply that formatting. We should likely use a field like `__format_type` that is part of each Dataclass as a key for identifying formatting rules.

		On the client, formatting rules should be applied in the order they are defined in the list. This means that if a rule is defined later in the list, it will take precedence over a rule defined earlier in the list. There should be a `stop_if_true` or equivalent property which would not apply any further formatting rules of the same type (e.g. background color) once a matching rule has been applied. This should make it possible to still apply different formatting types even if `stop_if_true` is `True`.


		##### ui.table Column Formatting Rules

		Column formatting rules apply to specific columns. All column formatting rules should have a `column` field which is the column the rule applies to. We could optionally support `columns` (or just a `columns` prop which handles both cases) which would allow for a list of columns that the rule applies to.


		With any of the options we could support some method of applying value formatting to all columns that support it. We could have an argument such as `all_columns=True` that would apply the rule to all columns that support it. This would be useful for number formatting, date formatting, etc.

		We could also support regex (or just wildcards) in the `cols` field to apply the rule to multiple columns at once. This could be useful if a user wanted to format all columns that end in percent as a percentage. Something like `FORMAT(cols=".*Percent", format="0.00%")`

docs: Table formatting spec #889

docs: Table formatting spec #889

Conversation

mattrunyon commented Sep 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsmmcken commented Sep 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsmmcken commented Sep 23, 2024

mattrunyon commented Sep 23, 2024 • edited Loading

mattrunyon commented Sep 23, 2024

mofojed left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattrunyon commented Sep 30, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattrunyon commented Oct 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattrunyon commented Oct 14, 2024

mattrunyon commented Sep 16, 2024 •

edited

Loading

dsmmcken commented Sep 18, 2024 •

edited

Loading

mattrunyon commented Sep 23, 2024 •

edited

Loading

mattrunyon commented Oct 2, 2024 •

edited

Loading