Add window states API #2473

proneon267 · 2024-04-02T16:50:29Z

Design discussion: #1884

The following are the API changes:

On the interface:

`toga.constants.WindowState`
`WindowState.NORMAL`
`WindowState.MAXIMIZED`
`WindowState.MINIMIZED`
`WindowState.FULLSCREEN`
`WindowState.PRESENTATION`

`toga.Window`
Added	`toga.Window.state`(getter)
	`toga.Window.state`(setter)
Deprecated	`toga.Window.full_screen`(getter)
	`toga.Window.full_screen`(setter)

`toga.App`
Added	`toga.App.is_in_presentation_mode`(getter)
	`toga.App.enter_presentation_mode()`
	`toga.App.exit_presentation_mode()`
Deprecated	`toga.App.is_full_screen`(getter)
	`toga.App.set_full_screen()`
	`toga.App.exit_full_screen()`

On the backend:

`toga.Window`
Added	`get_window_state()`
	`set_window_state()`

`toga.App`
Added	`enter_presentation_mode()`
	`exit_presentation_mode()`

However, I did encounter some issues, which I have put as inline comments. I do have some other questions about rubicon for implementing the new API, but I will post them later on.

TODO: Write and modify documentation, fix issues with tests, implement for the other remaining platforms, etc.

PR Checklist:

All new features have been tested
All new features have been documented
I have read the CONTRIBUTING.md file
I will abide by the code of conduct

proneon267 · 2024-04-04T02:06:55Z

@freakboy3742 Can you also review this, when you are free?

freakboy3742 · 2024-04-04T02:12:15Z

Unless there's a design or implementation issue that requires feedback, I generally don't review code until it's passing CI - this is currently failing coverage and Android tests, and I'm going to guess iOS tests as well (although #2476 is likely masking that problem).

Is there a specific design or implementation issue where you're seeking feedback prior to getting the tests to pass?

proneon267 · 2024-04-04T02:19:07Z

I needed some guide regarding the Android testbed, specifically test_app.py::test_full_screen and test_presentation_mode. I explained the issue with inline comments on test_app.py.

freakboy3742 · 2024-04-04T03:09:40Z

I needed some guide regarding the Android testbed, specifically test_app.py::test_full_screen and test_presentation_mode. I explained the issue with inline comments on test_app.py.

Well - I guess my first question is why is there anything to test at all? Mobile apps don't have any concept of "full screen" or "maximized"... even the representation of "window" is pretty loose. What behaviour are you implementing here?

Beyond that - if a test passes in isolation, but not as part of the suite, that usually indicates that one of the previous tests has left the test suite in an inconsistent state. A common example in the window tests is when a test leaves an open window (sometimes due to a test failing); subsequent checks of the window count then fail.

proneon267 · 2024-04-04T03:48:56Z

Well - I guess my first question is why is there anything to test at all? Mobile apps don't have any concept of "full screen" or "maximized"... even the representation of "window" is pretty loose. What behaviour are you implementing here?

Mostly Fullscreen and presentation mode where navigation bar, title bar& menu bars remain hidden.

Beyond that - if a test passes in isolation, but not as part of the suite, that usually indicates that one of the previous tests has left the test suite in an inconsistent state. A common example in the window tests is when a test leaves an open window (sometimes due to a test failing); subsequent checks of the window count then fail.

Yes, I realize that, in this case, the test seems to fail as they don't exit the presentation mode after testing. I thought maybe adding a delay to the redraw method would work, but it doesn't. The tests only pass when I set the window state directly on the window object or run the test in isolation.

I have also tried to identify any problems with the app interface but didn't find any. The same test logic is run in test_window, but there it works properly. The app implementation of presentation mode calls the window implementation of presentation mode. So, the behaviour should be identical.

proneon267 · 2024-04-05T00:37:46Z

@freakboy3742 Also could you also please take a quick peek at the mobile platforms tests on testbed of test_app.py::test_full_screen and test_presentation mode. Their implementation is identical to that of test_window.py::test_presentation_state, since the app APIs call into the window API endpoints.

freakboy3742 · 2024-04-05T01:01:41Z

@freakboy3742 Also could you also please take a quick peek at the mobile platforms tests on testbed of test_app.py::test_full_screen and test_presentation mode. Their implementation is identical to that of test_window.py::test_presentation_state, since the app APIs call into the window API endpoints.

I have, and I've already told you the general class of problem you're hitting. You've even hinted at the problem yourself:

Yes, I realize that, in this case, the test seems to fail as they don't exit the presentation mode after testing.

If a single test isn't leaving the app in the same state that it found it... well, that's the source of your problem. That's what you need to fix.

As for "the implementation is identical"... well, the golden rule of computers applies: if in doubt, the computer is right. The computer doesn't have opinions. It runs the code it has. If you think something is identical, but testing is producing inconsistent results... something about your implementation isn't identical.

You're the one proposing this PR; the onus is on you to solve problems with the implementation. If you've got a specific question about the way Toga or the testbed operates, then I can do what I can to provide an explanation, but I can only dedicate time to resolving an open ended "why doesn't it work?" questions when the problem is on my personal todo list - which usually means it's something on Toga's roadmap, or it's the source of a bug that is preventing people from using the published version of Toga.

proneon267 · 2024-05-23T06:40:11Z

The coverage report complains about:

Name              Stmts   Miss Branch BrPart  Cover   Missing
-------------------------------------------------------------
src/toga/app.py     [35](https://github.com/beeware/toga/actions/runs/9203102559/job/25314158711#step:6:36)7      2     82      2  99.1%   846, 852
-------------------------------------------------------------
TOTAL              5067      2   12[38](https://github.com/beeware/toga/actions/runs/9203102559/job/25314158711#step:6:39)      2  99.9%

toga/core/src/toga/app.py

Lines 846 to 849 in 06b7f2a

    
           @property 
        
           def is_in_presentation_mode(self) -> bool: 
        
               """Is the app currently in presentation mode?""" 
        
               return any(window.state == WindowState.PRESENTATION for window in self.windows)

So, Line 846 is just @property. I first thought maybe the is_in_presentation_mode property is not being invoked in the test, but it is invoked several times in the tests:

toga/core/tests/app/test_app.py

Line 468 in 06b7f2a

assert not app.is_in_presentation_mode

toga/core/tests/app/test_app.py

Line 480 in 06b7f2a

assert app.is_in_presentation_mode

Next, it reports missing coverage for Line 852:

toga/core/src/toga/app.py

Lines 851 to 854 in 06b7f2a

    
           def enter_presentation_mode( 
        
               self, 
        
               window_list_or_screen_window_dict: list[Window] | dict[Screen, Window], 
        
           ) -> None:

So, line 852 is just self,. Here also, `enter_presentation_mode() is invoked serveral times during the tests:

toga/core/tests/app/test_app.py

Line 479 in 06b7f2a

app.enter_presentation_mode({app.screens[0]: window1})

toga/core/tests/app/test_app.py

Line 494 in 06b7f2a

app.enter_presentation_mode([window1, window2])

So, both of these reported missing coverage don't make much sense to me.

Also, the tests expectedly fail on python 3.13 due to Pillow.

freakboy3742 · 2024-05-29T04:45:27Z

I can't work out what's going on with the coverage report in CI (perhaps a state cache somewhere?); but if I run the tests locally (tox -m test310), the lines in app.py that report as uncovered are 836 and 842, which corresponds nicely to to return conditions in set_full_screen():

toga/core/src/toga/app.py

Lines 830 to 843 in 06b7f2a

    
           #     DeprecationWarning, 
        
           #     stacklevel=2, 
        
           # ) 
        
           if self.windows is not None: 
        
               self.exit_full_screen() 
        
               if windows is None: 
        
                   return 
        
               screen_window_dict = dict() 
        
               for window, screen in zip(windows, self.screens): 
        
                   screen_window_dict[screen] = window 
        
               self.enter_presentation_mode(screen_window_dict) 
        
           else: 
        
               warn("App doesn't have any windows")

…to window_states

proneon267 · 2024-06-01T13:09:30Z

I can't work out what's going on with the coverage report in CI (perhaps a state cache somewhere?); but if I run the tests locally (tox -m test310), the lines in app.py that report as uncovered are 836 and 842, which corresponds nicely to to return conditions in set_full_screen():

Thanks! I was running the test locally with tox -e py; maybe that's why it wasn't showing the missing coverage. I have added the missing coverage and this PR is ready for a review.

freakboy3742

I've done an initial pass review of the core API; there's still a bunch of little details to sort out here. I've flagged some areas of interest; in general, if I've flagged a topic once, you can take it as written that the same comment applies to all other analogous issues.

In particular, the biggest areas needing attention are:

Handling of deprecated APIs. They need to raise warnings when used; test that they raise warnings when used; and their implementations should not call other deprecated APIs
Clarification of the state of full-screen and presentation mode.
Test parameterization. Rather than writing a single test that does a lot of things in sequence, it's preferable to have a parameterised test that does lots of individual changes. That way you get multiple failures when something unexpected changes, rather than a single test failure.

freakboy3742 · 2024-06-04T06:41:17Z

core/src/toga/app.py

+        #     ),
+        #     DeprecationWarning,
+        #     stacklevel=2,
+        # )
        self.exit_full_screen()


Presumably this should be exit_presentation_mode()

Modified it.

freakboy3742 · 2024-06-04T06:42:30Z

core/src/toga/app.py

+        screen_window_dict = dict()
+        for window, screen in zip(windows, self.screens):
+            screen_window_dict[screen] = window


Isn't this a duplicate of the logic in enter_presentation_mode?

Removed it.

freakboy3742 · 2024-06-04T06:43:18Z

core/src/toga/app.py

+    # ---------------------------------------------------------------------
+
+    @property
+    def is_in_presentation_mode(self) -> bool:


is_in_ is two prepositions. in_presentation_mode() is sufficient.

Thanks, I've modified it.

freakboy3742 · 2024-06-04T06:45:42Z

core/src/toga/app.py

+
+    def enter_presentation_mode(
+        self,
+        window_list_or_screen_window_dict: list[Window] | dict[Screen, Window],


windows would be a perfectly adequate argument name here. We don't need to do explicit typing in the variable name; _or_ in variable names is used in other APIs when there's an ambiguity between passing in other values.

Thanks, I've modified it.

freakboy3742 · 2024-06-04T06:47:51Z

core/src/toga/constants/__init__.py

+##########################################################################
+
+
+@unique


There's no need to use both unique and auto. The values are guaranteed to be unique.

Thanks, I've modified it.

freakboy3742 · 2024-06-04T06:58:24Z

core/tests/app/test_app.py

+    assert_action_not_performed(app, "exit presentation mode")
+
+    # Trying to enter full screen with no windows is a no-op
+    app.set_full_screen(None)


There's a difference between set_full_screen(), set_full_screen([]), and set_full_screen(None). I can't see any reason why the latter of these should be legal at all.

freakboy3742 · 2024-06-04T06:58:54Z

core/tests/app/test_app.py

    window1 = toga.Window()
    window2 = toga.Window()
-    app = toga.App(formal_name="Test App", app_id="org.example.test")

    assert not app.is_full_screen

    # If we're not full screen, exiting full screen is a no-op
    app.exit_full_screen()


If this is a deprecated API, then it should be in a pytest.warns.

Thanks, I've modified it.

freakboy3742 · 2024-06-04T07:03:34Z

core/tests/window/test_window.py

+    """A window can have different states."""
+    assert window.state == WindowState.NORMAL
+
+    for state in WindowState:


For loops in tests are generally an anti pattern - you should be using a parameterised test so that specific cases in the for loop can be identified as a problem. In this case, we're interested in all possible "initial state" to "final state" transitions.

I have parameterized the test.

freakboy3742 · 2024-06-04T07:15:33Z

core/src/toga/app.py

    ######################################################################

+    # ------------------------Deprecated methods--------------------------
+    # Warnings are disabled as old API tests are still in testbed and warnings will cause error.


This is what pytest.warns is for. It both silences the warning, and validates that a warning has been raised.

Thanks, I've modified it.

freakboy3742 · 2024-06-04T07:17:45Z

core/tests/app/test_app.py

+
+    assert not app.is_in_presentation_mode
+
+    # If we're not in presentation mode, exiting presentation mode is a no-op


Rather than one long test, it's better to have a large number of parameterised short tests - that way you can validate which specific pieces of behavior are failing, rather than getting a single "it's broken" test failure.

I have broken the tests of presentation mode into smaller tests, but they are not parameterized. This because, doing:

@pytest.mark.parametrize( "windows", [ [], [toga.Window()], [toga.Window(), toga.Window()], [toga.Window(), toga.Window(), toga.Window()], {}, {toga.App.app.screens[0]: toga.Window()}, { toga.App.app.screens[0]: toga.Window(), toga.App.app.screens[1]: toga.Window(), }, ], ) def test_presentation_mode_with_windows_list(event_loop, app, windows):

gives error, since the app is not instantiated. I have tried several variations of the above, but all of them gave error because of the app not being instantiated. I also found out that I cannot use pytest fixtures like app fixxture inside @pytest.mark.parametrize decorator.

Hence, I have instead broken down presentation mode test into smaller tests.

I have thought of another way to achieve parameterization of the test without creating additional tests, by:

@pytest.mark.parametrize( "num_of_windows, data_type", [ (0, list), (1, list), (2, list), (3, list), (0, dict), (1, dict), (2, dict), ], ) def test_presentation_mode_with_windows_list(event_loop, app, num_of_windows, data_type):

Then in the test body, I can dynamically create the number of required windows and the required data type of the windows parameter for the test.

Let me know if I should change the current core tests by the above parametrized test. But I don't think the above parameterized test is any clearer; in fact, it would become more unclear and harder to debug on test failures.

In general, I'd advise away from this as an approach. Tests should have as little logic in them as possible - because otherwise, you've got additional logic that needs to be tested. Sometimes logic is unavoidable; but if the option is slightly more verbose code or logic, go with verbose code.

Also - when picking test cases, be wary of what it is you're actually testing. What does validating the 2 window case tell you that 3 windows doesn't? Unless there's a good reason why the 2 and 3 case is different, there's no need to include both.

proneon267 · 2024-11-20T18:04:36Z

testbed/tests/window/test_window.py

+            )
+        ],
+    )
+    async def test_window_state_rapid_assignment(


This new test ensures complete coverage of this PR on macOS and gtk. So, I have removed all #pragma: no cover from this PR.

ok... but it also seems like a direct reproduction of the previous test, but without the (implied) delay between state changes.

Prior to this PR, the testbed takes ~3:20 to complete on macOS ARM64. As of the most recent CI run on this PR, it took almost 7 minutes to run. Window state changes aren't fast - and there's a lot of tests needed here.

For a backend that doesn't have any delay issues (like Windows), this test is identical to the window state change test. And for some macOS/GTK states, it will also be identical.

In an ideal world - yes, we'd run all these tests, reflecting every possible permutation "done fast". However, these tests are slow, so we need to ensure we're only testing what we need to test.

There's even an argument to be made that the two tests are the same test, but with some transitions having a boolean "...and wait" condition between the two state changes.

cocoa/tests_backend/window.py

proneon267 · 2024-11-28T07:00:41Z

I am thinking of ignoring window state requests when the window is hidden i.e., Window.visible is False. This should prevent any unexpected showing up of the window when the user has explicitly hidden the window.

proneon267 · 2024-11-28T11:42:35Z

I did a few more tests and found out that resizing the window while in FULLSCREEN or PRESENTATION, can cause glitches. So, I am also ignoring window resizing requests while in FULLSCREEN or PRESENTATION state.

freakboy3742 · 2024-11-29T00:36:37Z

There's currently a merge conflict - I'm guessing this has been introduced by the landing of #2993.

proneon267 · 2024-11-29T02:48:15Z

I also have found out that changing the window position while in FULLSCREEN or PRESENTATION can also cause glitches. So, I am also going to ignore window position requests while in FULLSCREEN or PRESENTATION state.

…tate.

freakboy3742 · 2024-11-29T03:20:10Z

I did a few more tests and found out that resizing the window while in FULLSCREEN or PRESENTATION, can cause glitches. So, I am also ignoring window resizing requests while in FULLSCREEN or PRESENTATION state.

I don't deny this is a problem - but the last time I looked at this PR, it was really close, except for some clarification around some test cases. You've now added a new functionality, which requires new tests, and all of that code will need to go through a review process, and likely multiple revisions - so the date where this PR gets merged is pushed off a little more.

It's perfectly acceptable to land a PR that has known issues, as long as those issues are documented. In this case, I'm guessing the issue is pre-existing; so it's not even an issue with this PR - you've just discovered it because it's adjacent to window state issues.

The code is here now, so it's not worth pulling it out - but if you want this PR to eventually land, you have to draw a line somewhere. :-)

proneon267 · 2024-11-29T04:18:58Z

I agree with you, I should have fixed them in separate PRs. From now on, if I find any more issues then I'm going to fix them in separate PRs. If it helps, the 3 "ignore window state requests" fixes that I have added are in the core. I will not make any more changes to this PR and would document out new issues separately.

freakboy3742

As expected, the new additions need some modifications; and we're still not quite there with the "test that used to be the intermediate tests". As noted inline, it seems to that the two tests are actually the same - just with a "do you want me to wait for completion before moving to the next state?" qualifier.

cocoa/src/toga_cocoa/window.py

freakboy3742 · 2024-11-29T03:52:55Z

core/src/toga/window.py

@@ -390,6 +390,8 @@ def size(self) -> Size:

    @size.setter
    def size(self, size: SizeT) -> None:
+        if self.state in {WindowState.FULLSCREEN, WindowState.PRESENTATION}:
+            raise ValueError(f"Cannot resize window while in {self.state}")


This isn't really a ValueError - there's nothing wrong with the value. I'd suggest a RuntimeError, as it's an error due to request being invalid due to the state at runtime.

The docstring for the property should also describe that size can't be changed when in fullscreen/presentation mode (using a :raises: annotation).

These two comments also apply to the position and screen_position properties.

I have added docstrings to size, position, screen_position.

freakboy3742 · 2024-11-29T03:54:37Z

gtk/src/toga_gtk/window.py

-                    # Add slight delay to prevent glitching  on wayland during rapid
-                    # state switching.
+                    # Add a 10ms delay to wait for the native window state
+                    # operation to complete to prevent glitching  on wayland


Minor typo here

Suggested change

# operation to complete to prevent glitching on wayland

# operation to complete to prevent glitching on wayland

freakboy3742 · 2024-11-29T04:24:58Z

core/src/toga/window.py

+    @state.setter
+    def state(self, state: WindowState) -> None:
+        if not self.visible:
+            raise ValueError("Window state of a hidden window cannot be changed.")


As above - this should be a documented RuntimeError.

I have added docstrings to state.

freakboy3742 · 2024-11-29T04:52:46Z

testbed/tests/window/test_window.py

+            )
+        ],
+    )
+    async def test_window_state_rapid_assignment(


ok... but it also seems like a direct reproduction of the previous test, but without the (implied) delay between state changes.

Prior to this PR, the testbed takes ~3:20 to complete on macOS ARM64. As of the most recent CI run on this PR, it took almost 7 minutes to run. Window state changes aren't fast - and there's a lot of tests needed here.

For a backend that doesn't have any delay issues (like Windows), this test is identical to the window state change test. And for some macOS/GTK states, it will also be identical.

In an ideal world - yes, we'd run all these tests, reflecting every possible permutation "done fast". However, these tests are slow, so we need to ensure we're only testing what we need to test.

There's even an argument to be made that the two tests are the same test, but with some transitions having a boolean "...and wait" condition between the two state changes.

proneon267 · 2024-11-29T17:35:14Z

Adding a boolean to indicate waiting between states can work, but I think it would introduce additional logic to the test and would create more confusion in case of a failure, like it was happening when I had the tests combined. I agree that testing all rapid state changes would be impractical. Hence, I have identified and kept only the most complex states.

freakboy3742 · 2024-12-02T00:56:20Z

Adding a boolean to indicate waiting between states can work, but I think it would introduce additional logic to the test and would create more confusion in case of a failure, like it was happening when I had the tests combined. I agree that testing all rapid state changes would be impractical. Hence, I have identified and kept only the most complex states.

I'm uncertain what you're proposing here. Are you suggesting there are more changes required to this PR? I'm unclear what an additional boolean would give us that the pending handling doesn't already give us.

proneon267 · 2024-12-02T01:40:23Z

No I am not proposing any changes to the code. I was referring to this boolean:

There's even an argument to be made that the two tests are the same test, but with some transitions having a boolean "...and wait" condition between the two state changes

freakboy3742

Ok - I think we're finally there. Thanks for the persistence with this PR; it's taken a while, but I feel like the final product has ended up in a good place.

proneon267 · 2024-12-02T04:29:02Z

Thank you for keeping patience with me. Next, I am planning to break up #2484 into 3 PRs: one for Android, one for iOS and one for winforms for easy reviewing. With any luck, I am hoping to complete them or at least some of the PRs before the end of the year.

proneon267 added 5 commits May 22, 2024 13:38

Minor modifications

ab9b778

Minor modifications

0a90a12

Minor modifications

73721b3

Fixed bug on Window.close()

c809698

Fixed dummy backend

06b7f2a

proneon267 and others added 8 commits June 1, 2024 01:56

Fixed tests

11fea69

Minor cleanup

938504c

Code Cleanup

be87113

Merge branch 'window_states' of https://github.com/proneon267/toga in…

9aefd30

…to window_states

Merge branch 'beeware:main' into window_states

13d2ff3

Code Cleanup

176e879

Merge branch 'window_states' of https://github.com/proneon267/toga in…

1ba73b8

…to window_states

Restart CI for Linux Testbed failure

d4bfdaa

freakboy3742 requested changes Jun 4, 2024

View reviewed changes

proneon267 and others added 6 commits June 12, 2024 12:49

Merge branch 'main' into window_states

d993b80

Updated to latest main branch

38bf5c3

Parameterized test on core

b710eaf

Merge branch 'main' into window_states

b461295

Updating to latest main branch

0c7900b

Changed attribute to is_presentation_mode

97a6c66

Removed stray comments

68b0a44

proneon267 requested a review from freakboy3742 November 20, 2024 17:51

proneon267 commented Nov 20, 2024

View reviewed changes

cocoa/tests_backend/window.py Show resolved Hide resolved

Ignore window state requests on a hidden window

0d807f6

proneon267 force-pushed the window_states branch from abfa4e8 to 0d807f6 Compare November 28, 2024 11:02

Ignore window resize requests while in fullscreen or presentation state.

9add077

Merge branch 'main' into window_states

35a49a1

Ignore window position requests while in fullscreen or presentation s…

c7ce202

…tate.

freakboy3742 requested changes Nov 29, 2024

View reviewed changes

Added docstrings

23319cf

proneon267 force-pushed the window_states branch from 7e13dc6 to 18aef1a Compare November 29, 2024 15:59

Reduce test cases for rapid state assignment

5b5e44a

proneon267 force-pushed the window_states branch from 560cfc9 to 5b5e44a Compare November 29, 2024 16:54

proneon267 requested a review from freakboy3742 December 2, 2024 01:42

freakboy3742 approved these changes Dec 2, 2024

View reviewed changes

freakboy3742 merged commit 1c8b7d4 into beeware:main Dec 2, 2024
40 checks passed

proneon267 deleted the window_states branch December 2, 2024 10:29

mhsmith mentioned this pull request Dec 4, 2024

Testbed failure in test_window_state_rapid_assignment #3016

Closed

HalfWhitt mentioned this pull request Dec 22, 2024

Removed 0.4.0 deprecations, for 0.5.0 #3059

Merged

4 tasks

		##########################################################################


		@unique


		assert not app.is_in_presentation_mode

		# If we're not in presentation mode, exiting presentation mode is a no-op

	# operation to complete to prevent glitching on wayland
	# operation to complete to prevent glitching on wayland

Add window states API #2473

Add window states API #2473

Conversation

proneon267 commented Apr 2, 2024 • edited by freakboy3742 Loading

On the interface:

On the backend:

PR Checklist:

proneon267 commented Apr 4, 2024

freakboy3742 commented Apr 4, 2024

proneon267 commented Apr 4, 2024

freakboy3742 commented Apr 4, 2024

proneon267 commented Apr 4, 2024

proneon267 commented Apr 5, 2024

freakboy3742 commented Apr 5, 2024

proneon267 commented May 23, 2024 • edited Loading

freakboy3742 commented May 29, 2024

proneon267 commented Jun 1, 2024 • edited Loading

freakboy3742 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

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

proneon267 Jun 17, 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

proneon267 commented Nov 28, 2024

proneon267 commented Nov 28, 2024

freakboy3742 commented Nov 29, 2024

proneon267 commented Nov 29, 2024

freakboy3742 commented Nov 29, 2024

proneon267 commented Nov 29, 2024

freakboy3742 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

proneon267 commented Nov 29, 2024

freakboy3742 commented Dec 2, 2024

proneon267 commented Dec 2, 2024

freakboy3742 left a comment

Choose a reason for hiding this comment

proneon267 commented Dec 2, 2024

proneon267 commented Apr 2, 2024 •

edited by freakboy3742

Loading

proneon267 commented May 23, 2024 •

edited

Loading

proneon267 commented Jun 1, 2024 •

edited

Loading

proneon267 Jun 17, 2024 •

edited

Loading