Fix color definitions, only use variables to allow proper custom theme support … #4373

fooness · 2020-04-09T16:42:36Z

See previous discussion in element-hq/element-web#13082 …

This pull requests fixes some scss variable <-> css variable color definitions to improve custom theme support via config.json … and also adds the possibility to define custom font-family and font-family-monospace via config.json … plus the variable list was ordered/sorted by alphabet for each section, as this was most of the times the case, but sometimes not.

—
Signed-off-by: fooness

Example usage:

    "settingDefaults": {
        "custom_themes": [
            {
                "name": "Custom Light",
                "is_dark": false,
                "colors": {
                    "accent-color": "#b0b0b0",
                    "button-color": "#b0b0b0",
                    "font-family": "Inter, system-ui, -apple-system, 'Apple Color Emoji', Twemoji, 'Segoe UI Emoji', sans-serif",
                    "font-family-monospace": "'Roboto Mono', 'Apple Color Emoji', Twemoji, 'Segoe UI Emoji', monospace",
                    "highlight-color": "#f0f0f0",
                    "primary-color": "#e4093b",
                    "warning-color": "#ff4b55",
                    "sidebar-color": "#f5f5f5",
                    "roomlist-background-color": "#ffffff",
                    "roomlist-text-color": "#0f0f0f",
                    "roomlist-text-secondary-color": "#0f0f0f",
                    "roomlist-separator-color": "#f0f0f0",
                    "timeline-background-color": "#ffffff",
                    "timeline-text-color": "#0f0f0f",
                    "timeline-text-secondary-color": "#b0b0b0",
                    "username-color": "#0f0f0f"
                }
            }, {
                "name": "Custom Dark",
                "is_dark": true,
                "colors": {
                    "accent-color": "#4f4f4f",
                    "button-color": "#4f4f4f",
                    "font-family": "Inter, system-ui, -apple-system, 'Apple Color Emoji', Twemoji, 'Segoe UI Emoji', sans-serif",
                    "font-family-monospace": "'Roboto Mono', 'Apple Color Emoji', Twemoji, 'Segoe UI Emoji', monospace",
                    "highlight-color": "#1f1f1f",
                    "primary-color": "#e4093b",
                    "warning-color": "#b30356",
                    "warning-color": "#ff4b55",
                    "sidebar-color": "#1a1a1a",
                    "roomlist-background-color": "#0f0f0f",
                    "roomlist-text-color": "#f0f0f0",
                    "roomlist-text-secondary-color": "#f0f0f0",
                    "roomlist-separator-color": "#1f1f1f",
                    "timeline-background-color": "#0f0f0f",
                    "timeline-text-color": "#f0f0f0",
                    "timeline-text-secondary-color": "#4f4f4f",
                    "username-color": "#f0f0f0"
                }
            }
        ]
    }

…e support … see: element-hq/element-web#13082

nadonomy · 2020-04-09T18:17:04Z

This is a little difficult for me to review on behalf of @matrix-org/design as it looks to address tech debt, and concern how we architect our CSS.

@fooness Should this PR produce any visual changes?

@jryans do you have any input on how the PR may impact theming opportunities in future? How should we be reviewing this? Ad hoc build?

fooness · 2020-04-09T19:30:28Z

Should this PR produce any visual changes?

@nadonomy No visual changes in default theme is perfecftly fine. When customizing the theme via config.json, for example the buttons in the top and bottom right were not changed in color. The pull request fixes this, plus some more single elements that were not supported by custom themes, yet.

[…] how the PR may impact theming opportunities in future?

In the long run, it probably would be good to make some changes to the structure of ref/ as well as rename and redefine most variables … I feel like most variables are named rather context-sensitive (or semantic), but oftentimes already defined variables are then used in places absolutely out of their context and that makes things rather … complicated and cryptic.

Maybe something like: element-hq/element-web#12314

Also, I wish the following issue would be fixed rather soon. When this happend, I feel like I could color-change every element I wanted, and I hope that others would confirm … element-hq/element-web#12630

fooness · 2020-04-11T23:20:13Z

Added $header-divider-color to fix:

fooness · 2020-04-11T23:24:29Z

Added $event-timestamp-color: var(--timeline-text-secondary-color); to fix timestamp color …

fooness · 2020-04-11T23:30:41Z

Added $message-action-bar-border-color and $message-action-bar-hover-border-color to fix colors of message action bar …

fooness · 2020-04-12T01:56:40Z

fooness · 2020-04-12T13:14:09Z

Added $dialog-close-fg-color …

fooness · 2020-04-13T14:43:42Z

@nadonomy @jryans Could you please review this? Is there any more I could do to help you with this?

jryans · 2020-04-13T15:25:32Z

@nadonomy @jryans Could you please review this? Is there any more I could do to help you with this?

No need to ping again, it's in the review queue, and we'll take a look as time allows. 😄

jryans

Overall, this looks reasonable to me! It cleans up the custom variables and applies them to some spots that may have been missed or added later. There should be no impact to the default themes.

Mostly I'd like to know more about how existing custom themes might be affected first.

jryans · 2020-04-17T14:20:21Z

res/themes/light-custom/css/_custom.scss

-$accent-color-alt: var(--primary-color);
-$input-focused-border-color: var(--primary-color);
+// --username-color
+$username-variant1-color: var(--username-color);


Here and in a few other places, you've added new variables to be set by the custom theme. Was it the effect for older custom themes that don't have a value username-color set?

The effect for older custom themes which don’t set this css variable is … none, I’m pretty sure? If the default theme is used, the custom variables are ignored all together. If a custom theme is used, then only the defined custom variables (in config.json) are changed, all non-defined variables just fall back to their default values. Right?

If a custom theme is used, then only the defined custom variables (in config.json) are changed, all non-defined variables just fall back to their default values. Right?

I don't think this is true. SASS definitiions like $username-variant1-color are compile-time, and they can't fall back on previous definitions of the same variable depending on the runtime value of a CSS variable.

I wonder if $username-variant1-color: var(--username-color, $username-variant1-color); would work though, using the default value argument in var to refer to the previous value of the SASS variable.

I wonder if $username-variant1-color: var(--username-color, $username-variant1-color); would work though, using the default value argument in var to refer to the previous value of the SASS variable.

Having carefully read through the specs of CSS var(), I think you’re pretty right with this proposal.

Do you have a quick way to absolutely validate this?

jryans · 2020-04-17T14:25:38Z

@jryans do you have any input on how the PR may impact theming opportunities in future? How should we be reviewing this? Ad hoc build?

Overall this shouldn't affect the future of theming much. It adds one or two new colours for custom theme users and default themes are unaffected.

Maybe the screens above are good enough for you, or else please request an ad-hoc build from @fooness.

…buttons (now accent-color, was falsely timeline-text-color before)

…buttons (now button-color, was falsely timeline-text-color before)

…ing $topleftmenu-color

fooness · 2020-04-19T15:43:37Z

This last fix was quite challenging in the end, but now it’s working properly (without breaking or modifying anything unintended, for sure). Unfortunately the key was slighly touching a second file, res/css/views/rooms/_AppsDrawer.scss … seems the two rightmost icon buttons, popout and menu, where simply missing the background-color attribute for their respective mask-image at all.

I changed the following …

.mx_AppTileMenuBar_iconButton {
    […]
    background-color: $topleftmenu-color;
    […]
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_minimise {
    mask-image: url('$(res)/img/feather-customised/widget/minimise.svg');
    background-color: $accent-color;
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_maximise {
    mask-image: url('$(res)/img/feather-customised/widget/maximise.svg');
    background-color: $accent-color;
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_popout {
    mask-image: url('$(res)/img/feather-customised/widget/external-link.svg');
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_menu {
    mask-image: url('$(res)/img/icon_context.svg');
}

… to the solution below:

.mx_AppTileMenuBar_iconButton {
    […]
    background-color: $topleftmenu-color;
    […]
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_minimise {
    mask-image: url('$(res)/img/feather-customised/widget/minimise.svg');
    background-color: $accent-color;
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_maximise {
    mask-image: url('$(res)/img/feather-customised/widget/maximise.svg');
    background-color: $accent-color;
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_popout {
    mask-image: url('$(res)/img/feather-customised/widget/external-link.svg');
    background-color: $accent-color;
}

.mx_AppTileMenuBar_iconButton.mx_AppTileMenuBar_iconButton_menu {
    mask-image: url('$(res)/img/icon_context.svg');
    background-color: $accent-color;
}

Sorry for the hustle in the last minute. My last change does not negate anything written by @jryans above.

bwindels · 2020-04-27T09:20:50Z

@fooness are these the CSS variables that are added in this PR?:

--username-color
--font-family
--font-family-monospace

Are there any others I missed in the PR?

I like the addition of font variables! I'm not 100% sold though that having one custom variable for all user name categories is better than not being able to theme them at all and relying on the default, as the point of colouring display names is to be able to visually distinguish (similar) display names.

Wrt to using using the existing CSS variables in more places, we probably need to verify to some extent that this doesn't break other themes too much, as they might rely on the built-in values.

The font-family part (if we get fallback to the built-in font working) should be straightforward to get in though. If you would like to get this part in quickly, feel free to PR it separately.

bwindels · 2020-04-27T09:27:50Z

res/themes/light-custom/css/_custom.scss

-// --roomlist-highlights-color
-$roomtile-selected-bg-color: var(--roomlist-highlights-color);
+// --font-family
+$font-family: var(--font-family);


We need a default here for older custom themes. Does this make it fall back to the default Nunito if --font-family is empty?:

$font-family: var(--font-family, $font-family);

fooness · 2020-04-27T09:35:04Z

@fooness are these the CSS variables that are added in this PR?:
* `--username-color`

* `--font-family`

* `--font-family-monospace`

@bwindels That’s true.

Are there any others I missed in the PR?

No, there’s no others.

I like the addition of font variables!

Great!

I'm not 100% sold though that having one custom variable for all user name categories is better than not being able to theme them at all and relying on the default, as the point of colouring display names is to be able to visually distinguish (similar) display names.

They don’t have to be modified if one is okay with the default.

But also it would be possible to have eight variables for config.json, each defining one of the user name sass variables. I thought it’s better to address all at once, if not happy with the default. But I get your point and it’s also possible to set all names the same color with eight css variables, it’s just more lines of code.

What do you prefer?

Wrt to using using the existing CSS variables in more places, we might probably need to verify to some extent that this doesn't break other themes too much.

I don’t think that might happen, as the very most of the other variables where not part of _custom.scss before because, as it seems, they were just missed. So basically in other custom themes these elements where not styled different then in the default theme as the theme authors had no possibility of changing them.

fooness · 2020-04-27T11:30:06Z

What’s the problem now? The logs don’t suppose it has anything to do with the changes in my last commit?

Please merge in current develop into your branch to fix the build.

Hope I did that correctly.

Accidently clicked close pull request instead of cancelling this comment. Whoops!

bwindels · 2020-04-27T11:36:38Z

I don’t think that might happen, as the very most of the other variables where not part of _custom.scss before because, as it seems, they were just missed. So basically in other custom themes these elements where not styled different then in the default theme as the theme authors had no possibility of changing them.

_custom.scss is not the root file for custom theming, it is light-custom.scss and dark-custom.scss, which does pull in a lot of other stuff, like _light.scss, and _dark.scss repectively, which provide defaults for anything missing in _custom.scss

Not exactly sure I do understand the problem then, as light-custom.scss, dark-custom.scss, _light.scss, and _dark.scss were basically not touched during/for this pull request. Or am I thinking wrong about this? In that case, sorry for not knowing better.

These files provided values for the SASS variables that are now being set with one of the existing CSS variable in this PR. The CSS variable might not be the same value as what it had before. So for example, some themes might look a bit off now that $tagpanel-button-color: var(--button-color);.

fooness · 2020-04-27T12:13:35Z

I don’t think that might happen, as the very most of the other variables where not part of _custom.scss before because, as it seems, they were just missed. So basically in other custom themes these elements where not styled different then in the default theme as the theme authors had no possibility of changing them.

_custom.scss is not the root file for custom theming, it is light-custom.scss and dark-custom.scss, which does pull in a lot of other stuff, like _light.scss, and _dark.scss repectively, which provide defaults for anything missing in _custom.scss

Not exactly sure I do understand the problem then, as light-custom.scss, dark-custom.scss, _light.scss, and _dark.scss were basically not touched during/for this pull request. Or am I thinking wrong about this? In that case, sorry for not knowing better.

These files provided values for the SASS variables that are now being set with one of the existing CSS variable in this PR. The CSS variable might not be the same value as what it had before. So for example, some themes might look a bit off now that $tagpanel-button-color: var(--button-color);.

Oh okay, that’s what you mean. Please let me refer to the https://github.com/aaronraimist/riot-web-themes repo and provide some screenshots.

These buttons basically were not re-styled in the custom themes, as no variables were assigned to them in _custom.scss … so all other custom themes will now be able to custom-color those buttons, too. Else it will fall back to $tagpanel-button-color: #91A1C0; (for light) and #a1b2d1 (for dark) … (or so I thought.)

$ grep -r tagpanel-button-color *
res/themes/light-custom/css/_custom.scss:$tagpanel-button-color: var(--button-color);
res/themes/light/css/_light.scss:$tagpanel-button-color: #91A1C0;
res/themes/dark/css/_dark.scss:$tagpanel-button-color: $header-panel-text-primary-color;

$ grep -r header-panel-text-primary-color *
res/themes/dark/css/_dark.scss:$header-panel-text-primary-color: #a1b2d1;
res/themes/dark/css/_dark.scss:$muted-fg-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$tagpanel-button-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$roomheader-button-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$groupheader-button-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$rightpanel-button-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$composer-button-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$header-divider-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$roomtile-name-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$message-action-bar-fg-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$message-action-bar-hover-border-color: $header-panel-text-primary-color;
res/themes/dark/css/_dark.scss:$reaction-row-button-hover-border-color: $header-panel-text-primary-color;

roomlist-highlights-color and timeline-highlights-color are now controlled, like other highlight-colors, via the single highlight-color … same applies to buttons. The goal was streamlining theming as far as it’s possible for now.

Having made the styling (and grouping and wording) of variables more consistent and complete, I think it’s possible that at first glance some custom themes might look slightly different to before. But with adding the new variables it should be possible to get a result similar to the current custom theme status but more complete support throughout the team.

I cannot guarantee for this, so, I guess, every other contributor cannot guarantee that nothing will change in the theming for like ever. Maybe someone with custom themes could check this for themselves and validate?

Overall, there’s still lots of things that need to be done for absolute theming support. This pull request is just the beginning and basically shows what was possible with only changes to the _custom.scss file (besides one exception) and kind of is everything that I found unsupported in the current state of custom variables.

EDIT: And … please don’t get me wrong. I’m more than happy about contributions, feedback, and overall progress in the theming possibilities of riot-web. But, I fear, at some point there’s more to change than just adding some variables here and there to achieve the best result and make theming as easy as possible. But that’s something that’s probably already on the roadmap for the devs and I fear that also is more complicated than I’m capable of (and also needs some governance and consensus among the devs and the community).

bwindels · 2020-04-27T15:02:40Z

res/themes/light-custom/css/_custom.scss

-// --roomlist-highlights-color
-$roomtile-selected-bg-color: var(--roomlist-highlights-color);
+// --font-family
+$font-family: var(--font-family, $font-family);


This will also need a check to not calculate different alpha values for font variables in theme.js

bwindels · 2020-04-27T15:03:50Z

I'm working on something myself that needs custom theming support, which some changes that may overlap with this PR. Will comment here when I know more.

bwindels · 2020-04-27T18:09:18Z

See #4503 for my changes. I've implemented the styling of usernames slightly different there. See element-hq/element-web#13406 for doc updates of how it is supposed to work.

fooness · 2020-04-27T18:13:06Z

See #4503 for my changes. I've implemented the styling of usernames slightly different there. See vector-im/riot-web#13406 for doc updates of how it is supposed to work.

Sounds and looks great. Thank you!

What should I do now? Remove the usernames variables from my pull request?

bwindels · 2020-04-27T18:13:57Z

What should I do now? Remove the usernames variables from my pull request?

Yeah, that would probably be easiest. Thank you.

…-color-definitions

fooness · 2020-04-27T18:18:40Z

What should I do now? Remove the usernames variables from my pull request?

Yeah, that would probably be easiest. Thank you.

Should be done.

nadonomy · 2020-04-29T00:47:30Z

Just wary this is still outstanding in the @matrix-org/design queue. @bwindels pls could you tag me into a comment when this has passed code review and I can review from there?

…atch reaction pill tooltip)

fooness · 2020-04-29T14:20:01Z

Unify reaction-pill-tooltip and text-input-markdown-tooltip on :hover … that is, in detail, one change and one add:

Make $interactive-tooltip-bg-color identical to $tooltip-timeline-bg-color … (previously --sidebar-color) …

$interactive-tooltip-bg-color: var(--timeline-text-secondary-color);
$tooltip-timeline-bg-color: var(--timeline-text-secondary-color);

Add $interactive-tooltip-fg-color to _custom.css, give same value as already existing $tooltip-timeline-fg-color …

$interactive-tooltip-fg-color: var(--timeline-background-color);
$tooltip-timeline-fg-color: var(--timeline-background-color);`

—

Also: added updates from @bwindels … that is: b187066, 2f68f60, and 8b8b525 (with --highlight-color instead of --timeline-highlight-color) …

fooness · 2020-06-11T11:18:05Z

@bwindels As this PR seems to be pretty abandoned by now, may I kindly ask you to add the possibilities of custom font-families (sans-serif and monospace) and custom button colors (see below, still the same problem as ever) — fixed in this PR — to your next PR?

e.g. the Matrix server name in the Explore menu and the sub-headline in the server dropdown
e.g. the back-chevron in the user menu (see below)

e.g. the All Rooms in room search (see below)

Probably forgot some elements … all of those — if I remember correctly — would have been fixed by this PR but are still not-styleable in Riot-Web 1.6.0–1.6.4 … which is pretty sad for everyone not using the default theme (and I’m pretty sure that’s many people).

t3chguy · 2020-06-11T12:59:31Z

custom font

is being tracked at element-hq/element-web#9403

bwindels · 2020-06-23T16:13:04Z

I'm working on font support for custom themes in #4814 fwiw

bwindels · 2020-07-31T08:42:42Z

So, apologies for the long delay. After having another look at this, there are at least the following things that prevent this from getting merged:

This seems to also add a highlight-color and button-color custom theme/CSS variable, but it's not explained why this is needed, nor if it breaks any existing themes that don't have it. Adding new variables is something we consider carefully because once custom themes rely on it, we can't easily change it anymore.
font support has since been added to mainline as mentioned, so that would have to be removed here.
reordering code in the same commit as other changes makes things really hard to review. In general, please split up your commits with more detailed commit messages so changes can be more easily reviewed one by one.
As discussed above, I'm still unsure whether this will break existing custom themes. Have you done any testing?

In general, when making changes in these parts that are a bit more fragile like custom theming, I would encourage to explain in great detail why you're making the changes you made, and what checks you have done to make sure it does not break anything. Smaller PRs that don't do several things at once also have a higher changes of getting through quickly.

Thanks for bearing with us.

bwindels

See comment above

acxz · 2022-04-09T06:06:24Z

@turt2live should this be closed as well in lieu of #7726 (comment) ?

turt2live · 2022-04-09T06:31:29Z

I think so, though for this one I think it's age alone which makes it impossible for us to reasonably merge this. Thanks for spotting!

Fix color definitions, only use variables to allow proper custom them…

d395017

…e support … see: element-hq/element-web#13082

turt2live requested a review from a team April 9, 2020 16:44

turt2live added the Z-Community-PR Issue is solved by a community member's PR label Apr 9, 2020

turt2live requested a review from a team April 9, 2020 16:45

fooness mentioned this pull request Apr 11, 2020

Widget app/title bar icons have different colors … element-hq/element-web#13107

Closed

fix header divider color

840f724

fix timestamp color

b533087

fix message action bar border color

7d3b49d

add username-color variable

266f79b

fooness mentioned this pull request Apr 12, 2020

Disable colored usernames for accessibility … element-hq/element-web#13102

Open

fix dialog border color

5352e8d

undo add button-primary-fg-color

07e9aa8

jryans reviewed Apr 17, 2020

View reviewed changes

fooness added 3 commits April 18, 2020 13:03

fix $topleftmenu-color in widget bar: needs same color as other icon …

2d0718a

…buttons (now accent-color, was falsely timeline-text-color before)

fix $topleftmenu-color in widget bar: needs same color as other icon …

9c4d396

…buttons (now button-color, was falsely timeline-text-color before)

finally fix those mx_AppTileMenuBar_iconButton colors without chang…

ece64a5

…ing $topleftmenu-color

bwindels suggested changes Apr 27, 2020

View reviewed changes

fooness reopened this Apr 27, 2020

bwindels reviewed Apr 27, 2020

View reviewed changes

bwindels mentioned this pull request Apr 27, 2020

Support setting username and avatar colors in custom themes #4503

Merged

Merge remote-tracking branch 'upstream/develop' into fix-custom-theme…

a1d6bb7

…-color-definitions

remove changes to usernames due to #4503

9679ec6

fooness added 2 commits April 29, 2020 16:16

add changes from @bwindels, improve text input markdown tooltip (to m…

8e2c9e2

…atch reaction pill tooltip)

manual merge with changes from @bwindels

0db4f50

fooness requested review from bwindels and removed request for a team April 29, 2020 14:32

bwindels assigned fooness Jul 31, 2020

bwindels suggested changes Jul 31, 2020

View reviewed changes

fooness mentioned this pull request May 18, 2021

fix theming by no longer hardcoding color values, and switching to new default font element-hq/element-web#17348

Open

acxz mentioned this pull request Feb 6, 2022

custom theme refactor #7726

Closed

turt2live closed this Apr 9, 2022

Fix color definitions, only use variables to allow proper custom theme support … #4373

Fix color definitions, only use variables to allow proper custom theme support … #4373

Conversation

fooness commented Apr 9, 2020 • edited Loading

nadonomy commented Apr 9, 2020

fooness commented Apr 9, 2020 • edited Loading

fooness commented Apr 11, 2020

fooness commented Apr 11, 2020

fooness commented Apr 11, 2020

fooness commented Apr 12, 2020 • edited Loading

fooness commented Apr 12, 2020 • edited Loading

fooness commented Apr 13, 2020

jryans commented Apr 13, 2020

jryans left a comment

Choose a reason for hiding this comment

jryans Apr 17, 2020

Choose a reason for hiding this comment

fooness Apr 17, 2020 • edited Loading

Choose a reason for hiding this comment

bwindels Apr 27, 2020

Choose a reason for hiding this comment

bwindels Apr 27, 2020

Choose a reason for hiding this comment

fooness Apr 27, 2020

Choose a reason for hiding this comment

jryans commented Apr 17, 2020

fooness commented Apr 19, 2020

bwindels commented Apr 27, 2020 • edited Loading

bwindels Apr 27, 2020

Choose a reason for hiding this comment

fooness commented Apr 27, 2020

fooness commented Apr 27, 2020

bwindels commented Apr 27, 2020

fooness commented Apr 27, 2020 • edited Loading

bwindels Apr 27, 2020

Choose a reason for hiding this comment

bwindels commented Apr 27, 2020

bwindels commented Apr 27, 2020

fooness commented Apr 27, 2020

bwindels commented Apr 27, 2020 • edited Loading

fooness commented Apr 27, 2020

nadonomy commented Apr 29, 2020

fooness commented Apr 29, 2020

fooness commented Jun 11, 2020

t3chguy commented Jun 11, 2020

bwindels commented Jun 23, 2020

bwindels commented Jul 31, 2020

bwindels left a comment

Choose a reason for hiding this comment

acxz commented Apr 9, 2022 • edited Loading

turt2live commented Apr 9, 2022

fooness commented Apr 9, 2020 •

edited

Loading

fooness commented Apr 9, 2020 •

edited

Loading

fooness commented Apr 12, 2020 •

edited

Loading

fooness commented Apr 12, 2020 •

edited

Loading

fooness Apr 17, 2020 •

edited

Loading

bwindels commented Apr 27, 2020 •

edited

Loading

fooness commented Apr 27, 2020 •

edited

Loading

bwindels commented Apr 27, 2020 •

edited

Loading

acxz commented Apr 9, 2022 •

edited

Loading