Lay the foundation for a Swift migration #547

DavidBertet · 2023-06-05T07:24:59Z

Summary

Laying the foundation for a Swift migration.

It should be easier to read/write, thus maintain, and new devs are more used to Swift than ObjC.

Is this something you would be interested in?

How did you test this change?

This is more of a PoC at this stage, that hasn't been fully tested

Built on iOS device & simulator and made sure examples worked the same.

scarlac · 2023-06-12T00:57:21Z

Yes, @DavidBertet, a Swift conversion/migration would be very welcome. We'd have to thoroughly test it on hardware devices as well, obviously. I have merged a few of your other PRs which may have caused the conflict you see.
If you are up for doing it, we very much welcome a Swift migration. Please proceed :)

DavidBertet · 2023-06-12T01:49:46Z

Thanks @scarlac for the merges! I'll rebase and move forward on the Swift conversion.

Agreed on the test, that will definitely be a big one.

Would you prefer multiple PRs that should be easier to review, or one with everything included?

scarlac · 2023-06-12T01:52:19Z

I think one big one is fine unless it’s more work for you that way.

DavidBertet · 2023-06-12T01:55:43Z

Sounds good, let's do one 👍

DavidBertet · 2023-06-30T07:52:12Z

Here we are @scarlac. Swift conversion/rewrite.

I extracted the logic that's unrelated to the actual camera into CameraView (focus, zoom, overlay, ...), which embeds either RealCamera or SimulatorCamera. That way, we can test much more things on the simulator.

The iOS barcode scanner was checking we aren't scanning twice the same value, I replaced it by a throttle configurable with scanThrottleDelay. In some use cases it seems legit for a user to scan twice the same in a row. Could easily be implemented on Android if you are aligned with the idea.

I removed setTorchMode which shouldn't have been exposed to React. It is redundant with the torchMode props. I'll remove it on Android if you are aligned.

I updated AVCaptureStillImageOutput that's deprecated to AVCapturePhotoOutput, and did a lot of things here and there.

I fixed a bunch of small issues here and there. Let me know how I can help further, that's definitely a big one.

DavidBertet · 2023-07-02T06:52:53Z

Here is a side by side recording of ObjC vs Swift implementation

test-swift.mp4

(custom ratio overlay color doesn't work on master, which is why it doesn't appear on ObjC)

Perf are very very similar (milliseconds one another, with Objc or Swift randomly being first). I'm still testing thoroughly the feature set.
I found one issue around default focusMode that should be on while not set from React. I'll check all default values.

scarlac · 2023-07-03T17:25:09Z

Excellent, @DavidBertet - I've also been testing it and it generally seems good. I am however removing the CameraScreen component as well as updating the tests to use functional components. I'll commit to your branch as well.

I don't know that there is a use case for the throttled barcode scanner, but I think it's an OK for this PR.
We need a follow up PR that has the ability to toggle that behavior, for example an optional ignoreDuplicateScans={false} and then throttleScans={2000}.
I think it is most likely that people are not interested in scanning the same code twice. From experience, you either want to scan immediately, or scan multiple items, in which case you want to ignore items that you already scanned. Since the rate of scanning differs on each platform, spamming the RN bridge is not a good default due to performance issues.
As an example, QR codes, and multiple barcodes can often appear close to each other on products.

Using hooks/functional components Fixed zoom on second pinch Fixed orientation issues Added support for new ultra wide camera (fix blurry close ups)

Added support for thumbnails (for later) Fixed default zoom to be wide angle camera instead of ultra wide

Remove cameraType from the class, use local variable only to avoid unwanted side effects Move thumbnail creation into delegate, to be consistent and return only data Make `counterRotatedCaptureVideoOrientationFrom` private Refactor slightly `update(pinchVelocity` Remove `setTorchMode`, add `scanThrottleDelay` from React types

DavidBertet

Nice! Thanks for your updates @scarlac!! I pushed a few things, and added some questions inlined

About throttling barcodes, my use case is to let users scan barcode of products they bought. iOS is so quick that pointing a product returns immediately it multiple times, but they might have bought the same product twice. Throttling permits to let the user move to the next barcode, that might happen to be the same value.

I get your use case about ignoreDuplicateScans. Today it was only "the last". So a product with multiple barcodes/qrCode would still spam randomly React, depending what it read last. You are thinking about ignoring duplicates for the whole session? (then let's switch that discussion to an issue :))

DavidBertet · 2023-07-04T06:51:34Z

ios/ReactNativeCameraKit/RealCamera.swift

+ if orientationNew == self.deviceOrientation {
+ return
+ }
+ self.deviceOrientation = orientationNew


Using the accelerometer is a great addition!

2 feedbacks

I would have kept that in CameraView as this code isn't related to the actual AV camera. It could benefit simulator implementation (and futur tests, or others). Then the computed orientation is forwarded to the camera implementation be taken into account.

Shouldn't we update self.cameraPreview.previewLayer.connection?.videoOrientation here?

CMMotionManager won't work in the simulator, so it needs to be in the specific implmenentation. The rotation you can do with the simulator does not cause "actual" motion.

I tried that. No, videoOrientation mustn't always be updated based on motion. Only after a significant change in orientation, or only taking a picture. Otherwise, UI orientation and motion may counter-indicate, causing video to be landscape, while UI is portrait or vice versa, which is technically correct but confusing to the user.
Please keep it as is, as I spent a significant amount of time testing all the use cases. You need to consider UI portrait (locked + unlocked), UI landscape left+right (not recommended but iPad UIs may need it), and every 3D rotation of the phone as well (portrait, landscape left, landscape right, upside down, 45 degree angle (=meaning no change from past orientation). If you compare the native iOS camera, it has the same behavior - where UI elements indicate portrait, but the captured photo is landscape. And that is what you'd want it to.

DavidBertet · 2023-07-04T07:55:06Z

ios/ReactNativeCameraKit/RealCamera.swift

@@ -149,21 +159,20 @@ class RealCamera: NSObject, CameraProtocol, AVCaptureMetadataOutputObjectsDelega
 }
 }

- func update(zoomScale: CGFloat) {
- guard !zoomScale.isNaN else { return }
+ func update(pinchVelocity: CGFloat, pinchScale: CGFloat) {


Not sure what you tried here? It seems exact same code as mine, with dividerFactor being 10 instead of 20. I rollbacked the code a bit, kept 10.

10 is very snappy on my iPhone, barely usable

pinchScale isn't used. is it intended?

I see. I had re-written it to use scale without velocity (so it's always linear to pinch size, and you can zoom far in and out at the cost of accuracy). That's why you see it. I then realized that the native camera uses velocity and tried to match it, however velocity is very finicky and as you zoom further in, it becomes harder to zoom out, esp if the phone is sluggish. Not clear what math the native camera uses.
I'm fine with going with 20 for now, but it needs to be well tested, otherwise we should use the scale-based zooming.

What makes you feel they are using velocity?
Native zoom seems to be capped at x10 which is roughly a zoomFactor of 20 on my iPhone (while videoMaxZoomFactor is like 180). Image at 20 is already kinda bad, not sure why they allow 180

Using scale + capping at 20 feels fairly similar to the native app. Miles better than all attempts I did with velocity. I pushed it so you can try. Let me know

PS: resetting pinchRecognizer.scale to 1.0 every time value changes is key to make the algorithm work

Yeah maybe. At first it looked like it was using velocity but after further inspection and using the grid on the native camera to align my fingers, it looks like there's no velocity involved.
In that case, we do need the pinchRecognizer.scale and the original code I wrote to use scale to zoom (which I unfortunately never committed).

DavidBertet · 2023-07-04T07:57:35Z

ios/ReactNativeCameraKit/CameraView.swift

 if pinchRecognizer.state == .changed {
- camera.update(zoomScale: zoomScale)
+ camera.update(pinchVelocity: pinchRecognizer.velocity, pinchScale: pinchRecognizer.scale)


If we do want to use pinchRecognizer.scale here (seems not used)

Should put the line pinchRecognizer.scale = 1.0 first?

Or move it when we set it up?

Well, not sure what it does :D and it's late...

Doesn't matter a ton to me. I was just playing with various algorithms to get an improved behavior.

DavidBertet · 2023-07-04T08:02:54Z

ios/ReactNativeCameraKit/RealCamera.swift

@@ -244,36 +253,33 @@ class RealCamera: NSObject, CameraProtocol, AVCaptureMetadataOutputObjectsDelega
 self.update(torchMode: self.torchMode)
 }
 }
-
+
+ func counterRotatedCaptureVideoOrientationFrom(deviceOrientation: UIInterfaceOrientation) -> AVCaptureVideoOrientation? {


What do you mean by counterRotate? seems like just a type conversion (at least as of now)

I was very tired and had to finish up. It was because UI and hardware orientation are opposed to each other in landscape mode (device is rotated left, so UI must rotate right to be readable).
The switch was indeed counter rotating until the end.
I think it's because initializeMotionManager is already counter-rotating the device orientation, which is a bug.

So it may be worth checking if we should:

Keep the name the same

Change initializeMotionManager so it doesn't counter-rotate

Change the initial value of self.deviceOrientation when it's initialized to the UI orientation such that it also counter-rotates back (so if UI is in landscape-left, device orientation must be assumed to be landscape-right).

Gotcha, I'm currently looking at 2.

@scarlac I refined the orientation implementation. Let me know what you think - feel free to revert if you preferred yours

Every time UIDeviceOrientation is converted to AVCaptureVideoOrientation, we counter rotate it
It applies to

Accelerometer, which is now setting deviceOrientation (UIDeviceOrientation), not counter rotated

uiOrientationChanged, by accessing device.orientation

(requires a yarn bootstrap)

UIDeviceOrientation and AVCAptureVideoOrientation are not the same thing. They are conceptually different and so you cannot use them as the same value.
When you orient the device left, the UI must rotate right. The counter-rotation function is necessary.
Can we undo those changes? The code is necessary. You cannot simplify it to the same value. We must have the actual device orientation, both for onOrientationChange() events and for selectively updating the video stream orientation. Both are needed, separately, for separate purposes.

Yes, I think we are aligned.

Current code does counter rotate when converting device to interface/video. Everything is exact same as yours. I only fixed the bug so initializeMotionManager doesn't counter rotate deviceOrientation, BUT happens later while used.

What's misleading is the name UIDeviceOrientation which contains UI & Device

UIDeviceOrientation is physical / device

UIInterfaceOrientation is interface

AVCAptureVideoOrientation is video, synced with interface

Converting UIDeviceOrientation to UIInterfaceOrientation/AVCAptureVideoOrientation requires counter rotation left/right.
That counter rotation is abstracted in the conversion extension, so as a consumer they don't have to know about those subtleties

Asking for .videoOrientation from a UIInterfaceOrientation IS NOT counter rotated

Asking for .videoOrientation from a UIDeviceOrientation IS counter rotated

I'm fine using methods, it's mainly code style.

DavidBertet · 2023-07-04T08:05:42Z

ios/ReactNativeCameraKit/CameraView.swift

@@ -262,15 +262,21 @@ class CameraView: UIView {
 }
 }

- private func writeCaptured(imageData: Data, 
+ private func writeCaptured(imageData: Data,
+ thumbnailData: Data?,


Are you getting a thumbnail? Seems like we have to explicitly enable it

If you requested a preview image by specifying the previewPhotoFormat property of your photo settings when requesting capture, this property offers access to the resulting preview image pixel data

https://developer.apple.com/documentation/avfoundation/avcapturephoto/2873984-previewpixelbuffer

Yeah, it's just laying some preparation for later changes. I had it working locally but have not committed enabling it since it needs several other features enabled and must be an opt-in feature. We can leave it in for now.

DavidBertet · 2023-07-04T08:46:19Z

ios/ReactNativeCameraKit/RealCamera.swift

+ the main thread and session configuration is done on the session queue.
+ */
+ DispatchQueue.main.async {
+ var videoPreviewLayerOrientation = self.counterRotatedCaptureVideoOrientationFrom(deviceOrientation: self.deviceOrientation) ?? self.cameraPreview.previewLayer.connection?.videoOrientation


The variable self.deviceOrientation seems clashing with self.cameraPreview.previewLayer.connection?.videoOrientation

Sticking to one source of truth might help to understand the code, and avoid cases where they are un-synced

If we want to prioritize accelerometer orientation against interface orientation we should make that clear, and sooner

Everytime accelerometerOrientation or interfaceOrientation changes, we should do
previewLayer.connection?.videoOrientation = accelerometerOrientation ?? interfaceOrientation

When we take the picture, we just use previewLayer.connection?.videoOrientation

As explained in other comments - no. videoOrientation is not the same as device orientation. You do not always want them to be similar, unfortunately. It comes back to the fact that UIs can rotate, which cause a disconnect between physical orientation and what we know is the right orientation. We do want this disconnect, but we don't want the UI to show it.
If you use the native camera, you'll see that it has the same behavior. UI elements may not rotate, and video stream wont, but captured picture does.

Got it! Thanks for the explanation, makes sense now.

Could we make it extra clear by renaming deviceOrientation with physicalOrientation / orientationFromAccelerometer?

I think deviceOrientation is accurate. It's the orientation of the device. The only confusion is that UI orientation, video orientation, and device orientation are all 3 separate concepts that we need to juggle.

scarlac · 2023-07-04T18:45:59Z

If you remove setTorchMode then be careful since it's also implemented in Android and was requested by a few users already:
#523

I honestly don't think setTorchMode is something we should have imperatively - that's what props are for, so if we remove it we need to remove on both platforms and be give an example of what to do instead in a changelog.

DavidBertet · 2023-07-04T19:40:59Z

If you remove setTorchMode then be careful since it's also implemented in Android and was requested by a few users already: #523

I honestly don't think setTorchMode is something we should have imperatively - that's what props are for, so if we remove it we need to remove on both platforms and be give an example of what to do instead in a changelog.

Fully aligned. I wanted your insight before to put it back / remove it from Android.

It comes from a bug, where defaulting torchMode to 'on' doesn't work.
The right fix is to address the timing issue like I did on iOS. Torch should be delayed until camera is ready
The workaround should be to delay setting torchMode by a few ms, than creating another way of doing it.
I'll take a look after this PR being merge.

Make initializeMotionManager private Use extensions for conversions Handle accelerometer updates on background thread Use UIDeviceOrientation for deviceOrientation Converting UIDeviceOrientation to Interface/VideoOrientation counter-rotate it

DavidBertet · 2023-07-04T22:25:36Z

While looking for leaks, I noticed the CKCameraManager is retained when we go back to the main screen

It is released/deinit as soon as we open a new one.

I put that here just in case you have any idea why, might be a React Native thing

scarlac · 2023-07-05T16:12:21Z

As a general comment, try to avoid making extensions. Extensions are non-obvious and global. They can come from anywhere. It makes code hard to read and understand for newcomers so it should be limited to use cases where we cannot do it in a more obvious way.

(I noticed that scaleZoomFactor was moved into the extension, which is unnecessary)

scarlac · 2023-07-05T16:29:23Z

If you remove setTorchMode then be careful since it's also implemented in Android and was requested by a few users already: #523
I honestly don't think setTorchMode is something we should have imperatively - that's what props are for, so if we remove it we need to remove on both platforms and be give an example of what to do instead in a changelog.

Fully aligned. I wanted your insight before to put it back / remove it from Android.

It comes from a bug, where defaulting torchMode to 'on' doesn't work. The right fix is to address the timing issue like I did on iOS. Torch should be delayed until camera is ready The workaround should be to delay setting torchMode by a few ms, than creating another way of doing it. I'll take a look after this PR being merge.

Cool. Let's get rid of setTorchMode on both platforms then.

On a separate note, the code doesn't compile right now. Please make sure I can also run the latest commit that's pushed so I can verify we don't create a regression.

DavidBertet · 2023-07-05T16:34:15Z

On a separate note, the code doesn't compile right now. Please make sure I can also run the latest commit that's pushed so I can verify we don't create a regression.

Did you run yarn bootstrap? I added a file, which requires a pod install

DavidBertet · 2023-07-05T17:35:38Z

As a general comment, try to avoid making extensions. Extensions are non-obvious and global. They can come from anywhere. It makes code hard to read and understand for newcomers so it should be limited to use cases where we cannot do it in a more obvious way.

(I noticed that scaleZoomFactor was moved into the extension, which is unnecessary)

Extensions became fairly common in mobile native world, but agree might be non-obvious developers used to other paradigms.

First, I'm aligned on not spreading logic around.

I used them here only to extract uninteresting boilerplate, not related to the actual camera logic. Like locking configuration to update torchMode / zoomFactor (which can be easily missed), or converting one type to another.
Benefit of having them here is we can easily unit test them, contrary to private methods in consumer class.

However, as you said, if bypassed/duplicated because unknown, it's not any better :)

I can update the code, what do you recommend? My only advice would be to write code that could be unit tested, because there is quite a few subtle things that could be broken fairly easily

scarlac · 2023-07-06T06:08:46Z

As a general comment, try to avoid making extensions. Extensions are non-obvious and global. They can come from anywhere. It makes code hard to read and understand for newcomers so it should be limited to use cases where we cannot do it in a more obvious way.

(I noticed that scaleZoomFactor was moved into the extension, which is unnecessary)

Extensions became fairly common in mobile native world, but agree might be non-obvious developers used to other paradigms.

First, I'm aligned on not spreading logic around.

I used them here only to extract uninteresting boilerplate, not related to the actual camera logic. Like locking configuration to update torchMode / zoomFactor (which can be easily missed), or converting one type to another.

Benefit of having them here is we can easily unit test them, contrary to private methods in consumer class.

However, as you said, if bypassed/duplicated because unknown, it's not any better :)

I can update the code, what do you recommend? My only advice would be to write code that could be unit tested, because there is quite a few subtle things that could be broken fairly easily

Normal functions or public functions can be unit tested. We needn’t unit test every single method though.
Private methods in this context do not help. They are a way to hide methods that we don’t want exposed but we aren’t writing a Swift API so there is no contract to keep or hide, so if it helps, feel free to make it a public method or expose any other methods too.

scarlac · 2023-07-06T06:19:31Z

While looking for leaks, I noticed the CKCameraManager is retained when we go back to the main screen

It is released/deinit as soon as we open a new one.

I put that here just in case you have any idea why, might be a React Native thing

RN modules are kept in memory unless we actively delete our stuff. We probably can’t rely on deinit but must use viewDidHide (or whatever the equivalent might be that actually works here).
That’s my only thought right now.
It would be nice to fix although I’d say it’s not important to getting this particular PR merged. It’s likely an old issue if my theory holds up.

`torchMode` props should be used instead

DavidBertet · 2023-07-06T08:54:36Z

@scarlac I pushed the things we talked about. Let me know if I forgot anything.

FYI I noticed the examples are broken on Android. Bottom bar appears just below top bar

scarlac · 2023-07-07T06:16:15Z

@scarlac I pushed the things we talked about. Let me know if I forgot anything.

FYI I noticed the examples are broken on Android. Bottom bar appears just below top bar

Ah yes, I'll try to have a look at that if you don't. I made some adjustments to the flexbox sizing of the elements and the viewport on Android has 0 height by default whereas iOS viewport is larger.

DavidBertet · 2023-07-07T17:18:38Z

Ah yes, I'll try to have a look at that if you don't. I made some adjustments to the flexbox sizing of the elements and the viewport on Android has 0 height by default whereas iOS viewport is larger.

👍. I can look at it, I just need to know what's the expected behavior.

On the existing CameraScreen the preview seems to be full screen on Android, while "centered" on iOS. But it probably means Android camera preview is cropped left/right?

Same, what do you expect for the preview. Full screen or centered.

I would go centered for both platform/use case to simplify the example, but let me know what you expected

scarlac · 2023-07-07T20:16:14Z

Ah yes, I'll try to have a look at that if you don't. I made some adjustments to the flexbox sizing of the elements and the viewport on Android has 0 height by default whereas iOS viewport is larger.

👍. I can look at it, I just need to know what's the expected behavior.

On the existing CameraScreen the preview seems to be full screen on Android, while "centered" on iOS. But it probably means Android camera preview is cropped left/right?

Same, what do you expect for the preview. Full screen or centered.

I would go centered for both platform/use case to simplify the example, but let me know what you expected

Centered, yes. 4:3 locked format for this example, as you've probably noticed. It's for a future update to somehow detect camera dimensions but the majority of camera/sensors are 4:3.
The challenge is that even 4:3 may be too large on some small/slim screens, so even centered can be a challenge. For the example project we shouldn't spend too much time optimizing the UI. In the end, it's just an example, not a "perfect" implementation.

DavidBertet · 2023-07-08T08:38:42Z

I pushed a first shot.

	iOS	Android
Zones
Real

My Android camera is cropped a bit, but might be acceptable.

What's not great is the Android scan target isn't centered anymore (but crop is, camera is cropped same size top/bottom)

Something to look at later

scarlac · 2023-07-10T18:03:59Z

Thanks David. I'll fix the frame on Android.

scarlac · 2023-07-12T00:35:58Z

Thank you so much @DavidBertet, this was extremely helpful! Hopefully this will encourage further high quality contributions now that we're mainly using Swift.
🎉

Lay the foundation for a Swift migration

9342a1d

DavidBertet force-pushed the task/swift_migration branch from 8125f1c to 9342a1d Compare June 12, 2023 02:01

DavidBertet added 4 commits June 27, 2023 21:21

Swift migration & rewrite

bdbfac1

Fix Git Action iOS build

baf3e11

Fix small issues, throttle scanner

d730a76

Remove prints & signpost

a23aa47

Remove unused protocol

01c2367

scarlac self-requested a review July 1, 2023 05:55

scarlac force-pushed the task/swift_migration branch from b8659e4 to f9b068f Compare July 4, 2023 03:17

scarlac added 3 commits July 3, 2023 20:21

Removed CameraScreen

5a7df3e

Rewrote example project

37737ac

Using hooks/functional components Fixed zoom on second pinch Fixed orientation issues Added support for new ultra wide camera (fix blurry close ups)

Fixed orientation issues for both orientation locked and rotated UIs

fee756b

Added support for thumbnails (for later) Fixed default zoom to be wide angle camera instead of ultra wide

scarlac force-pushed the task/swift_migration branch from f9b068f to fee756b Compare July 4, 2023 03:21

DavidBertet force-pushed the task/swift_migration branch from 1bfaa9f to 8b34666 Compare July 4, 2023 08:35

DavidBertet added 2 commits July 4, 2023 01:40

Make button targets bigger by adding some padding

d92b40b

Fix default zoomFactor when we switch camera

6c7e0fe

DavidBertet commented Jul 4, 2023

View reviewed changes

DavidBertet added 2 commits July 4, 2023 12:43

Using hooks/functional component for App

d738b6c

Refine orientation

13aed71

Make initializeMotionManager private Use extensions for conversions Handle accelerometer updates on background thread Use UIDeviceOrientation for deviceOrientation Converting UIDeviceOrientation to Interface/VideoOrientation counter-rotate it

DavidBertet force-pushed the task/swift_migration branch from 42d185d to 13aed71 Compare July 4, 2023 22:17

DavidBertet added 2 commits July 5, 2023 01:11

Try to match native app pinch to zoom

231bb30

Enable videoStabilization if supported

2f0195b

DavidBertet added 2 commits July 6, 2023 00:39

Remove extensions & unused pinch velocity

fedec20

Remove setTorchMode method on Android

b0048a0

`torchMode` props should be used instead

DavidBertet mentioned this pull request Jul 7, 2023

[ios 14] wrong orientation #347

Open

Rework UI to make it work on both platforms

5f10962

Fixed scan frame dimensions on Android

478a68b

scarlac force-pushed the task/swift_migration branch from 53602df to 478a68b Compare July 10, 2023 19:20

scarlac approved these changes Jul 12, 2023

View reviewed changes

scarlac merged commit 6e05414 into teslamotors:master Jul 12, 2023
0 of 3 checks passed

DavidBertet mentioned this pull request Jul 22, 2023

Frame in android are cut #494

Closed

Lay the foundation for a Swift migration #547

Lay the foundation for a Swift migration #547

Conversation

DavidBertet commented Jun 5, 2023

Summary

How did you test this change?

scarlac commented Jun 12, 2023 • edited Loading

DavidBertet commented Jun 12, 2023

scarlac commented Jun 12, 2023

DavidBertet commented Jun 12, 2023

DavidBertet commented Jun 30, 2023

DavidBertet commented Jul 2, 2023 • edited Loading

scarlac commented Jul 3, 2023

DavidBertet 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

scarlac Jul 5, 2023 • edited Loading

Choose a reason for hiding this comment

DavidBertet Jul 4, 2023 • 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

DavidBertet Jul 4, 2023 • edited Loading

Choose a reason for hiding this comment

scarlac Jul 5, 2023 • edited Loading

Choose a reason for hiding this comment

DavidBertet Jul 5, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DavidBertet Jul 4, 2023 • 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

scarlac commented Jul 4, 2023

DavidBertet commented Jul 4, 2023

DavidBertet commented Jul 4, 2023

scarlac commented Jul 5, 2023 • edited Loading

scarlac commented Jul 5, 2023

DavidBertet commented Jul 5, 2023

DavidBertet commented Jul 5, 2023

scarlac commented Jul 6, 2023

scarlac commented Jul 6, 2023

DavidBertet commented Jul 6, 2023

scarlac commented Jul 7, 2023

DavidBertet commented Jul 7, 2023 • edited Loading

scarlac commented Jul 7, 2023

DavidBertet commented Jul 8, 2023

scarlac commented Jul 10, 2023

scarlac commented Jul 12, 2023

scarlac commented Jun 12, 2023 •

edited

Loading

DavidBertet commented Jul 2, 2023 •

edited

Loading

scarlac Jul 5, 2023 •

edited

Loading

DavidBertet Jul 4, 2023 •

edited

Loading

DavidBertet Jul 4, 2023 •

edited

Loading

scarlac Jul 5, 2023 •

edited

Loading

DavidBertet Jul 5, 2023 •

edited

Loading

DavidBertet Jul 4, 2023 •

edited

Loading

scarlac commented Jul 5, 2023 •

edited

Loading

DavidBertet commented Jul 7, 2023 •

edited

Loading