emoji: Fix bottom padding of emoji picker #1315

PIG208 · 2025-01-30T22:21:16Z

Previously, the body of the bottom sheet was wrapped in SafeArea. This pads the bottom unconditionally, shifting the bottom of the list view above the device bottom inset.

This is undesirable, because the area beneath the bottom inset is still visible, and the list view should extend to the bottom regardless of the bottom inset.

By just removing the SafeArea, the list view extends to the bottom. However, if the bottom inset is more than 8px, we can't scroll past the last item in the list view. Essentially, we want the behavior of SafeArea.minimum with a ListView — the bottom of the list should always be padded by at least 8px, so that we can scroll past the shadow; and if the bottom inset is more than 8px, use that as the padding instead — which is achieved through the use ListView.padding and MediaQuery.

PIG208 · 2025-01-30T22:22:39Z

Comparisons (older revision)

The bottom bar represents the device padding.

before (SafeArea + 8px bottom padding)	after `max(8px, bottom inset)` bottom padding
partially scrolled to the bottom, with shadow visible

fully scrolled to the bottom

with keyboard open, unscrolled

Comparisons (w/ `CustomScrollView` and `SilverSafePadding`)

before (SafeArea + 8px bottom padding)	after (`SilverSafePadding`)
partially scrolled to the bottom, with shadow visible

fully scrolled to the bottom

with keyboard open, unscrolled

(This set of screenshots appear consistent with the older implementation; both should fix this issue)

Comparisons (w/ `CustomScrollView` and `SilverSafePadding` and no shadow)

before (SafeArea + 8px bottom padding)	after (`SilverSafePadding`)
partially scrolled to the bottom

fully scrolled to the bottom

with keyboard open, unscrolled

The following patch was used to make the builds in the screenshots:

diff --git a/lib/widgets/app.dart b/lib/widgets/app.dart
index 2ad35e3e5..28a96cf68 100644
--- a/lib/widgets/app.dart
+++ b/lib/widgets/app.dart
@@ -201,6 +201,7 @@ class _ZulipAppState extends State<ZulipApp> with WidgetsBindingObserver {
   @override
   Widget build(BuildContext context) {
     final themeData = zulipThemeData(context);
+    final mediaQuery = MediaQuery.of(context);
     return GlobalStoreWidget(
       child: MaterialApp(
         onGenerateTitle: (BuildContext context) {
@@ -218,7 +219,21 @@ class _ZulipAppState extends State<ZulipApp> with WidgetsBindingObserver {
               (_) => widget._declareReady());
           }
           GlobalLocalizations.zulipLocalizations = ZulipLocalizations.of(context);
-          return child!;
+          return Center(child: Stack(
+            children: [
+              MediaQuery(
+                data: mediaQuery.copyWith(
+                  viewPadding: mediaQuery.viewPadding.copyWith(bottom: 30),
+                  padding: mediaQuery.padding.copyWith(bottom: 30),
+                ),
+                child: child!),
+              Positioned(
+                left: 0,
+                right: 0,
+                bottom: 0,
+                child: Container(height: 30, decoration: BoxDecoration(color: Colors.black.withValues(alpha: 0.5)))),
+            ],
+          ));
         },
 
         // We use onGenerateInitialRoutes for the real work of specifying the

chrisbobbe

Thanks! Comments below.

I stopped reading the tests when I realized they might not work with an alternative implementation I thought of. (Actually would it be possible to write a set of tests that would work with either/any implementation? That's generally preferable.)

chrisbobbe · 2025-02-08T01:04:06Z

lib/widgets/emoji_reaction.dart

+    // This does remove the bottom inset.
+    // Leave it to the descendent [ListView].
    useSafeArea: true,


I don't understand this yet—what do you mean by "remove the bottom inset"?

Here's the doc:

/// The [useSafeArea] parameter specifies whether the sheet will avoid system /// intrusions on the top, left, and right. If false, no [SafeArea] is added; /// and [MediaQuery.removePadding] is applied to the top, /// so that system intrusions at the top will not be avoided by a [SafeArea] /// inside the bottom sheet either. /// Defaults to false.

It doesn't say anything about controlling what's done about the bottom inset.

chrisbobbe · 2025-02-08T01:09:57Z

lib/widgets/emoji_reaction.dart

+          context: context,
+          // The bottom is padded below with `padding` within the [ListView].
+          removeBottom: true,
+          child: ListView.builder(


How about using CustomScrollView, with SliverPadding for the top padding and SliverSafeArea for the bottom padding? My feeling is that the code would be simpler; I'm curious if that turns out to be true. We use SliverSafeArea in a few places already.

Indeed! This works for me:

Expanded(child: InsetShadowBox( top: 8, bottom: 8, color: designVariables.bgContextMenu, child: CustomScrollView( slivers: [ SliverPadding( padding: EdgeInsets.only(top: 8), sliver: SliverSafeArea( minimum: EdgeInsets.only(bottom: 8), sliver: SliverList.builder( itemCount: _resultsToDisplay.length, itemBuilder: (context, i) => EmojiPickerListEntry( pageContext: widget.pageContext, emoji: _resultsToDisplay[i].candidate, message: widget.message)))), ]))),

PIG208 · 2025-02-10T21:13:15Z

Updated the PR, with new screenshots here: #1315 (comment).

The new implementation does require reworking the tests. I have updated them with an approach that should work just fine with the emoji picker implementation on main.

chrisbobbe · 2025-02-12T23:51:42Z

Thanks! Reviewing now.

One nit: I think this is the wrong column label in the table of screenshots for the current revision:

after max(8px, bottom inset) bottom padding

because the max approach isn't used in this revision. I think just a copy-paste error from the other table of screenshots.

chrisbobbe

Thanks! One design-level comment I noticed: now that the content can scroll all the way to the bottom edge of the screen (which I also think is an improvement), how about removing the InsetShadowBox shadow effect at the bottom? We don't have that effect on similar scrollables, such as the "Combined feed" message list.

The shadow effect makes the viewport edge more graceful when there's not already a clear boundary that coincides with it, but the screen edge is such a boundary. Similarly the top edge of the keyboard when that's open. (Clear definition of the top edge of the keyboard is the platform's job, not ours.)

I'd be happy to discuss more in #mobile-design if needed.

chrisbobbe · 2025-02-13T00:10:32Z

test/widgets/emoji_reaction_test.dart

+        final options = tester.widgetList(find.byType(EmojiPickerListEntry));
+        firstOption = options.first;
+        lastOption = options.last;


Suggested change

final options = tester.widgetList(find.byType(EmojiPickerListEntry));

firstOption = options.first;

lastOption = options.last;

final listEntryFinder = find.byType(EmojiPickerListEntry);

firstOption = tester.widget(listEntryFinder.first);

lastOption = tester.widget(listEntryFinder.last);

with the goal of leaning on flutter_test just a little bit more, in case it gives richer / more helpful feedback when a test fails—I don't know if it actually would in this case though.

Actually, with these chained finders (foo.first and foo.last), would we still need to store firstOption and lastOption to pass to a find.byWidget, or could we just used the chained finders directly?

chrisbobbe · 2025-02-13T00:15:20Z

test/widgets/emoji_reaction_test.dart

+      double getScrollChildrenTop(WidgetTester tester) =>
+        tester.getTopLeft(find.byWidget(firstOption)).dy;
+      double getScrollChildrenBottom(WidgetTester tester) =>
+        tester.getBottomLeft(find.byWidget(lastOption)).dy;


The name, return type, and implementation don't seem to fit with each other; I can say more if helpful.

Yeah, I kind of struggled naming these helpers. I meant to express that this fetches y-coord of the top-most/bottom-most edge of the scrollable content (scroll items/scroll list?).

Are double getScrollElementTopEdgeDy and double getScrollElementBottomEdgeDy better?

chrisbobbe · 2025-02-13T00:26:33Z

test/widgets/emoji_reaction_test.dart

+        // The top of the list of children is padded by 8px;
+        // the bottom is out of view.
+        check(scrollViewTop).equals(getScrollChildrenTop(tester) - 8);
+        check(scrollViewBottom).isLessThan(getScrollChildrenBottom(tester));


It looks like this assumes there's a very long list of children, but I'm not seeing that clearly in the setup code. Reading setupEmojiPicker, called by prepare, I think I see two items being set up?

store.setServerEmojiData(ServerEmojiData(codeToNames: { '1f4a4': ['zzz', 'sleepy'], // (just 'zzz' in real data) })); await store.handleEvent(RealmEmojiUpdateEvent(id: 1, realmEmoji: { '1': eg.realmEmojiItem(emojiCode: '1', emojiName: 'buzzing'), }));

The rest of them come from EmojiStore.popularEmojiCandidates.

The test controls the screen height so that the scroll view can be filled. I think we can add some additional checks in prepare to verify that.

chrisbobbe · 2025-02-13T00:39:29Z

lib/widgets/emoji_reaction.dart

+    // This removes insets from all sides except bottom.
+    // Leave it to the descendent [CustomScrollView].


I don't know what "removes insets" means. Taken literally, it doesn't make sense; the insets are features of the device (which might include hardware) that our app isn't able to remove.

How about:

// The bottom inset is left for [builder] to handle; // see [EmojiPicker] and its [CustomScrollView] for how we do that.

It's also possible that we don't need a comment at all, and the useSafeArea dartdoc is sufficient if readers are curious.

PIG208 · 2025-02-14T23:47:43Z

Thanks for the review! Just pushed a new revision addressing the comments, and updated the screenshots.

chrisbobbe

Thanks! Small comments on the tests, which actually I'm curious for Greg's thoughts on (so, marking for his review): one is a naming question, the other is about adding a helper that might be helpful but maybe not necessary.

chrisbobbe · 2025-02-20T01:33:40Z

test/widgets/emoji_reaction_test.dart

+        // This makes it easier to convert between device pixels used for
+        // [FakeViewPadding] and logical pixels used in tests.
+        tester.view.devicePixelRatio = 1.0;


This is a way to let callers use less code, but it doesn't really remove the caller's burden to think about the physical/logical pixel distinction. That's because callers are still asked to make a FakeViewPadding, and the dartdoc of that says it's in physical pixels, while the rest of the test code is naturally in logical pixels. Callers are asked to assume the pixel ratio is 1, but they're not asked explicitly, in prepare's interface (it has no dartdoc), so they have to look at this line in the implementation, to be sure.

It's helpful that we're not asking callers to do math with devicePixelRatio, but I think there's a more satisfying way to do that, and with something reusable. (Helpful because this is likely to come up again.) What if we did this:

New file, like test/test_window.dart

New private subclass of FakeViewPadding:

It implements a method FakeViewPadding resolve(double devicePixelRatio) that returns a plain FakeViewPadding, scaled from this by devicePixelRatio

Its left, top, right, and bottom getters throw errors saying that resolve must be called. (Or maybe call the superclass's getter just if the value is zero.) See for example the operator getter on ApiNarrowDm.

An extension on FakeViewPadding, adding a static method with return type FakeViewPadding, named something like fromLogicalPx, that creates and returns an instance of the private subclass

Then for these tests, callers would say:

FakeViewPadding.fromLogicalPx(bottom: 10)

and prepare would say

tester.view.viewPadding = viewPadding.resolve(devicePixelRatio);

This sounds useful but I think it's OK to skip it for these tests — this private prepare helper is used only by a couple of test cases right next to it, so it's OK that they depend on some details of it which aren't clearly described.

It'd be good to add a little comment here linking to the above PR comment to describe a cleaner way this could be done. That way if in the future we're doing something similar and consulting this code as an example, we'll see that and have the option to act on it.

chrisbobbe · 2025-02-20T01:42:11Z

test/widgets/emoji_reaction_test.dart

+      double getListEntriesTopEdgeOffset(WidgetTester tester) =>
+        tester.getTopLeft(listEntryFinder.first).dy;
+      double getListEntriesBottomEdgeOffset(WidgetTester tester) =>
+        tester.getBottomLeft(listEntryFinder.last).dy;


Are the finders restricted to list entries that are at least partially visible in the viewport, and do the tests depend on that? If so, maybe that should be reflected in these names. I agree naming these is hard 😅 #1315 (comment) —maybe Greg would have some thoughts, having recently worked with the sticky-header code.

These will find only list items that have actually been built and are present in the element tree.

The list will build items until either it runs out or it fills the viewport, plus 250px in either direction — the default value of [ScrollView.cacheExtent]. It looks like these tests never care about how far beyond the viewport the list items extend, as long as they extend beyond it at all — so the fact that cacheExtent is positive is enough to make things work.

gnprice

Thanks @PIG208 for fixing this, and @chrisbobbe for the previous reviews! Generally this looks good. Comments below.

gnprice · 2025-02-25T21:08:31Z

test/widgets/emoji_reaction_test.dart

    final searchFieldFinder = find.widgetWithText(TextField, 'Search emoji');
+    Finder findInPicker(Finder finder) =>


I like the name of this.

It should have a blank line to separate from the other declaration, because they're not both one-line declarations (nor closely related):

Suggested change

final searchFieldFinder = find.widgetWithText(TextField, 'Search emoji');

Finder findInPicker(Finder finder) =>

final searchFieldFinder = find.widgetWithText(TextField, 'Search emoji');

Finder findInPicker(Finder finder) =>

gnprice · 2025-02-25T21:14:28Z

test/flutter_checks.dart

@@ -169,3 +169,8 @@ extension TableChecks on Subject<Table> {
 extension IconButtonChecks on Subject<IconButton> {
  Subject<bool?> get isSelected => has((x) => x.isSelected, 'isSelected');
 }
+
+extension OffsetChecks on Subject<Offset> {


nit: keep the file organized more or less logically, rather than in the order we needed things; so put this near the top because it's from dart:ui, i.e. the engine; specifically just above Rect, because it's closely related to Rect but simpler

gnprice · 2025-02-25T21:20:07Z

test/widgets/emoji_reaction_test.dart

+        scrollViewTopEdgeOffset = tester.getTopLeft(scrollViewFinder).dy;
+        scrollViewBottomEdgeOffset = tester.getBottomLeft(scrollViewFinder).dy;
+        final scrollViewHeight = tester.getSize(scrollViewFinder).height;


nit: These facts can all be bundled together as a Rect:

Suggested change

scrollViewTopEdgeOffset = tester.getTopLeft(scrollViewFinder).dy;

scrollViewBottomEdgeOffset = tester.getBottomLeft(scrollViewFinder).dy;

final scrollViewHeight = tester.getSize(scrollViewFinder).height;

scrollViewRect = tester.getRect(scrollViewFinder);

Then references below to these three variables can instead use .top, .bottom, .height on the Rect.

Neat! I think we can make a helper for the list entries that returns a Rect too:

Rect getListEntriesRect(WidgetTester tester) => tester.getRect(find.byType(EmojiPickerListEntry).first) .expandToInclude(tester.getRect(find.byType(EmojiPickerListEntry).last));

gnprice · 2025-02-25T21:22:38Z

test/widgets/emoji_reaction_test.dart

+
+        // The top edge of the list entries is padded by 8px from the top edge
+        // of the scroll view; the bottom edge is out of view.
+        check(scrollViewTopEdgeOffset).equals(getListEntriesTopEdgeOffset(tester) - 8);


nit: line too long, key information past 80 columns

Suggested change

check(scrollViewTopEdgeOffset).equals(getListEntriesTopEdgeOffset(tester) - 8);

check(scrollViewTopEdgeOffset)

.equals(getListEntriesTopEdgeOffset(tester) - 8);

gnprice · 2025-02-25T21:30:37Z

test/widgets/emoji_reaction_test.dart

+      double getListEntriesTopEdgeOffset(WidgetTester tester) =>
+        tester.getTopLeft(listEntryFinder.first).dy;
+      double getListEntriesBottomEdgeOffset(WidgetTester tester) =>
+        tester.getBottomLeft(listEntryFinder.last).dy;


These will find only list items that have actually been built and are present in the element tree.

The list will build items until either it runs out or it fills the viewport, plus 250px in either direction — the default value of [ScrollView.cacheExtent]. It looks like these tests never care about how far beyond the viewport the list items extend, as long as they extend beyond it at all — so the fact that cacheExtent is positive is enough to make things work.

gnprice · 2025-02-25T21:36:28Z

test/widgets/emoji_reaction_test.dart

+        // This makes it easier to convert between device pixels used for
+        // [FakeViewPadding] and logical pixels used in tests.
+        tester.view.devicePixelRatio = 1.0;


This sounds useful but I think it's OK to skip it for these tests — this private prepare helper is used only by a couple of test cases right next to it, so it's OK that they depend on some details of it which aren't clearly described.

It'd be good to add a little comment here linking to the above PR comment to describe a cleaner way this could be done. That way if in the future we're doing something similar and consulting this code as an example, we'll see that and have the option to act on it.

PIG208 · 2025-02-26T04:36:38Z

Thanks! This is ready for review now.

gnprice

Thanks! One nit — otherwise all now looks good.

gnprice · 2025-02-26T05:08:19Z

test/widgets/emoji_reaction_test.dart

+        // The top edge of the list entries is padded by 8px from the top edge
+        // of the scroll view; the bottom edge is out of view.
+        Rect listEntriesRect = getListEntriesRect(tester);
+        check(scrollViewRect.top).equals(listEntriesRect.top - 8);


nit:

Suggested change

check(scrollViewRect.top).equals(listEntriesRect.top - 8);

check(scrollViewRect).top.equals(listEntriesRect.top - 8);

then combine with the next check as a cascade

PIG208 · 2025-02-26T23:07:42Z

Thanks! Updated the PR.

Signed-off-by: Zixuan James Li <[email protected]>

Previously, the body of the bottom sheet was wrapped in `SafeArea`. This pads the bottom unconditionally, shifting the bottom of the list view above the device bottom padding. This is undesirable, because the area beneath the bottom padding is still visible, and the list view should extend to the bottom regardless of the bottom inset. By just removing the `SafeArea`, the list view extends to the bottom. However, if the bottom padding is more than 8px, we can't scroll past the last entry in the list view. Essentially, we want the behavior of `SilverSafeArea.minimum` — the bottom edge of the list entries should always be padded by at least 8px, so that we can scroll past the shadow; and if the bottom padding is more than 8px, use that as the padding instead. Signed-off-by: Zixuan James Li <[email protected]>

We don't have other scrollables that are vertical, touching the bottom viewport edge, and have shadow there. This was brought up by Chris: > The shadow effect makes the viewport edge more graceful when there's not already a clear boundary that coincides with it, but the screen edge is such a boundary. Similarly the top edge of the keyboard when that's open. (Clear definition of the top edge of the keyboard is the platform's job, not ours.) CZO discussion: https://chat.zulip.org/#narrow/channel/530-mobile-design Signed-off-by: Zixuan James Li <[email protected]>

gnprice · 2025-03-04T00:35:25Z

Thanks! Looks good; merging.

PIG208 assigned chrisbobbe Jan 30, 2025

PIG208 added the maintainer review PR ready for review by Zulip maintainers label Jan 30, 2025

PIG208 force-pushed the pr-inset branch 2 times, most recently from ebfa257 to 584240c Compare January 30, 2025 23:06

PIG208 requested a review from chrisbobbe January 30, 2025 23:11

PIG208 changed the title ~~emoji: Fix bottom inset padding of emoji picker~~ emoji: Fix bottom padding of emoji picker Jan 30, 2025

chrisbobbe reviewed Feb 8, 2025

View reviewed changes

PIG208 force-pushed the pr-inset branch 2 times, most recently from da4794b to 0c1d767 Compare February 10, 2025 20:58

chrisbobbe reviewed Feb 13, 2025

View reviewed changes

PIG208 force-pushed the pr-inset branch from 0c1d767 to 776ae8a Compare February 14, 2025 23:46

PIG208 force-pushed the pr-inset branch from 776ae8a to a14315e Compare February 15, 2025 00:16

chrisbobbe reviewed Feb 20, 2025

View reviewed changes

chrisbobbe assigned gnprice and unassigned chrisbobbe Feb 20, 2025

chrisbobbe requested a review from gnprice February 20, 2025 01:56

chrisbobbe added integration review Added by maintainers when PR may be ready for integration and removed maintainer review PR ready for review by Zulip maintainers labels Feb 20, 2025

PIG208 force-pushed the pr-inset branch from a14315e to d48fa4c Compare February 21, 2025 01:42

gnprice reviewed Feb 25, 2025

View reviewed changes

PIG208 force-pushed the pr-inset branch from d48fa4c to 47e9fa4 Compare February 26, 2025 04:35

PIG208 requested a review from gnprice February 26, 2025 04:37

gnprice reviewed Feb 26, 2025

View reviewed changes

PIG208 force-pushed the pr-inset branch from 47e9fa4 to 6d1c2e2 Compare February 26, 2025 23:06

PIG208 requested a review from gnprice March 3, 2025 19:55

PIG208 added 3 commits March 3, 2025 16:31

emoji test: Make a more specific finder helper

a8c9d14

Signed-off-by: Zixuan James Li <[email protected]>

gnprice force-pushed the pr-inset branch from 6d1c2e2 to 78f58ac Compare March 4, 2025 00:35

gnprice merged commit 78f58ac into zulip:main Mar 4, 2025

PIG208 deleted the pr-inset branch March 19, 2025 20:45

PIG208 mentioned this pull request Mar 19, 2025

new_dm: Add UI for starting new DM conversations #1322

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

emoji: Fix bottom padding of emoji picker #1315

emoji: Fix bottom padding of emoji picker #1315

PIG208 commented Jan 30, 2025

PIG208 commented Jan 30, 2025 •

edited

Loading

chrisbobbe left a comment

chrisbobbe Feb 8, 2025

chrisbobbe Feb 8, 2025

PIG208 Feb 10, 2025

PIG208 commented Feb 10, 2025

chrisbobbe commented Feb 12, 2025

chrisbobbe left a comment •

edited

Loading

chrisbobbe Feb 13, 2025

chrisbobbe Feb 13, 2025

PIG208 Feb 14, 2025

chrisbobbe Feb 13, 2025

PIG208 Feb 14, 2025 •

edited

Loading

chrisbobbe Feb 13, 2025

PIG208 commented Feb 14, 2025

chrisbobbe left a comment •

edited

Loading

chrisbobbe Feb 20, 2025

gnprice Feb 25, 2025

chrisbobbe Feb 20, 2025

gnprice Feb 25, 2025

gnprice left a comment

gnprice Feb 25, 2025

gnprice Feb 25, 2025

gnprice Feb 25, 2025

PIG208 Feb 26, 2025

gnprice Feb 25, 2025

gnprice Feb 25, 2025

gnprice Feb 25, 2025

PIG208 commented Feb 26, 2025

gnprice left a comment

gnprice Feb 26, 2025

PIG208 commented Feb 26, 2025

gnprice commented Mar 4, 2025

		// This removes insets from all sides except bottom.
		// Leave it to the descendent [CustomScrollView].

		final searchFieldFinder = find.widgetWithText(TextField, 'Search emoji');
		Finder findInPicker(Finder finder) =>

	check(scrollViewTopEdgeOffset).equals(getListEntriesTopEdgeOffset(tester) - 8);
	check(scrollViewTopEdgeOffset)
	.equals(getListEntriesTopEdgeOffset(tester) - 8);

	check(scrollViewRect.top).equals(listEntriesRect.top - 8);
	check(scrollViewRect).top.equals(listEntriesRect.top - 8);

emoji: Fix bottom padding of emoji picker #1315

emoji: Fix bottom padding of emoji picker #1315

Conversation

PIG208 commented Jan 30, 2025

PIG208 commented Jan 30, 2025 • edited Loading

chrisbobbe 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

PIG208 commented Feb 10, 2025

chrisbobbe commented Feb 12, 2025

chrisbobbe left a comment • 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

PIG208 Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PIG208 commented Feb 14, 2025

chrisbobbe left a comment • 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

gnprice 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

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

PIG208 commented Feb 26, 2025

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PIG208 commented Feb 26, 2025

gnprice commented Mar 4, 2025

PIG208 commented Jan 30, 2025 •

edited

Loading

chrisbobbe left a comment •

edited

Loading

PIG208 Feb 14, 2025 •

edited

Loading

chrisbobbe left a comment •

edited

Loading