Improving Camera Conversion #54
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Really, thats a thing now? 😅 Not a fan, && is clearly readable for me, "," is not 🤷♂️. |
wat... Ok, I think I'd use this style specifically if I have a multi-condition if statement that also includes let bindings, because that's how the syntax works for those. But otherwise yeah this is less clear for me too. I'll disable that check. |
ianthetechie
added a commit
to michaelkirk/swiftui-dsl
that referenced
this pull request
Oct 7, 2024
ianthetechie
approved these changes
Oct 7, 2024
ianthetechie
added a commit
that referenced
this pull request
Oct 7, 2024
* Fix: recenter doesn't immediately take effect Note: I only ever reproduced the bug in the context my app, which uses this library via Ferrostar, while using the CoreLocationProvider, not the SimulatedLocationProvider. But I expect this to be an issue for anyone using this API. To reproduce the bug in my app: Setup: (all of this is working more or less as expected): - While stationary (not sure if this is required) - start a route - see the user location puck and map centered on my location on the ground. - pan the map off the route - see the user location puck disappear, but you still see the smaller location indicator on the map. (as expected) - see the "recenter me" button appear - tap the "recenter me" button Now here's the problem: At this point I'm expecting the map to recenter with the user location puck on my location on the ground. But instead, I see the user location puck centered at the *current* map position - where I'd previously panned to, *not* at my location on the ground. Interestingly, if you'd repeat the process at this point - panning and then re-tapping the "center me" button, it would *work* this second time. --- The new behavior is definitely an improvement. However, if you've zoomed way out while exploring the map away from your route, there is a slightly noticeable two-part action while we wait for the new completion block - first re-centering and then zooming. It's unquestionably better than the current behavior though. * Fixes from @hactar's branch * Disable swiftformat andOperator (see #54) * Fix inadvertent regression; update CHANGELOG --------- Co-authored-by: Ian Wagner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue/Motivation
I noticed that in certain situations, even though my camera was setup as pitchRange = .free, it kept switching to .freeWithinRange(0, 59.9999999). When back converting the MLNMapView camera we were missing determining the pitch range based on our enum: the camera would always be set to .freeWithinRange instead of trying to go for .free or .fixed too if applicable.
Tasklist