-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map cannot be rotated while zooming #5844
Comments
Not sure about v58, but in v59 (MapLibre), this is deliberate. There is a specific option to turn on this behavior, and it has been requested that this should be turned on in the past. |
What is the advantage of strictly separating the two gestures? Or what were the arguments for doing so? |
I don't remember. You can try looking through the discussion(s) in the PRs for integrating MapLibre. |
I can't find anything about it. I have searched all PRs for the following keywords: rotate, rotating, rotation, spin, turn, zoom, tilt
But I can't find any discussion about it. It would be interesting to know why an existing behaviour is changed. Especially if it has no advantages. |
Okay, we're talking about an issue not a PR - good to know ;) As far as I can summarise, the main factor was that users were frustrated because they accidentally rotated the map when they wanted to zoom. I'm just wondering if it's so profound to remove the entire feature. In the linked issue:
That means it would be a draw on paper. This also reflects the thumb reaction to post number 3. Even demsjf8 explicitly said that they didn't want the function to be removed - which it is now. Fun Fact: The most-used map application on each of the two major smartphone operating systems lets you zoom and rotate at the same time. |
They didn't want removed that you can rotate at all, that's how I understood it. |
I read this in the following order:
demsjf8:
|
Anyway, OrganicMaps for example doesn't allow rotating the map while zooming (but it allows zooming while rotating the map). This makes sense. Usually, when zooming, you don't want to rotate the map. While when you rotate, maybe you want to zoom a bit, too. The behavior in StreetComplete v59.0-alpha1 is exactly the same as in OrganicMaps. |
Are you sure or are you using a different version? I can rotate and zoom in all variants at the same time. My version is 2024.08.17-4.Google. Video only online for 2 days: https://streamable.com/6nx8vy |
My version is 2024.08.16-5-FDroid but I doubt that they changed it within one day. I can definitely zoom and rotate at the same time. But If I start it as a zoom gesture, I cannot rotate. When I start it as a rotate gesture, I can do both. Same as in StreetComplete v59.0-alpha1 |
Well what can I say, you can see what I do in my video, can't you? |
Yes, you start with rotating. You can do that too in StreetComplete v59.0-alpha1 |
Anyway, will close as will not fix, because more often one would want to zoom without rotating than the other way round. And if one wants to zoom with rotating, one can still just start with the rotating gesture, just like in OrganicMaps. |
I strongly request undoing what to me makes StreetComplete MUCH more annoying to navigate. You are clearly getting multiple people who want to be able to rotate/zoom freely while only some want the setting to change the navigation to this. Theres also 2 thumbs up on the issue i wrote initially before this one was linked. At least expose it as a setting so those who are annoyed by this can re-enable it. Theres also a notable difference to Organic Maps: in StreetComplete, navigating and especially rotating around is much more meccessary than when, for example, following a route. In any case, if you don't undo this downgrade, i'll have to request it from SCEE which i'm already using anyways, tho having it in SC would be far better as i promise you there'll be a bunch more people who dislike this change once the full v59 releases to various stores. |
I don't really see a problem with one gesture only doing zoom and one doing rotation and zoom - BUT a) I have a relatively new smartphone with no problems to decide between the two b) I don't have any condition that makes it harder for me to precisely move my fingers (i.e. arthritis) c) I get annoyed by almost any map rotation, I'm used to top-north physical maps. YET SC has behaved to accept both gestures at the same time forever, changing it now is what my software company would call a breaking change. Introducing a breaking change that is not economically necessary to keep product and customer alive is fine, but always needs to be reversible. This is even more important as #3022 has had a fair share of people being against changing the behaviour in the first place, so it's not something that has been uncontested for 3 years and "suddenly" "now" everybody is against it. I strongly vouch for an option button ("Allow map rotation and zoom at the same time", don't even phrase it as working in one way but not the other, that's been discussed at length here) and be done. So everyone can have it their way without going for SCEE. K |
This general claim is much too strong, often breaking changes are impossible to avoid. Or not reasonable to avoid. |
Often perhaps, but not in this case. Here, only |
as it very much sounds like it was a concious decision to as this being behavior i don't think it matters much that its impossible to avoid.
Just, allow users to change this. Don't dictate how users should navigate the map. Let them decide. Choose a default however you want, though i would advocate for the default being the old behaviour to stop this from being a breaking change. Its such a wierd small thing to be strict about. Different people have different preferences. If it sounds like i'm too passionate about this: kinda, yeah. I only started using StreetComplete recently, and after using it a LOT (top 50 worldwide last 7 days) i stumble across a crash in the old version, switch to the beta, and am faced with a annoying change only to find out it was on purpose due to 1 person requesting it in the past. |
I really have no opinion on what is preferable here but wanted to comment on something general...
this is necessary to some degree - alternative is having more settings than Osmand have and maintaining it. |
Then leave the behaviour people got used to in place. Don't go making entirely optional breaking changes if thats the issue. |
So, the current (new) behavior is that the map cannot be rotated when the zoom gesture has already been started first (but the other way round). This is new behavior in StreetComplete (since v59) but standard behavior in OrganicMaps. I too noticed that the thresholds for which gesture is detected are a bit different in MapLibre and OrganicMaps, in the latter it feels more natural while in MapLibre rarely I accidentally zoom even though I wanted to rotate. This is the issue that some users in this thread are mainly complaining about. Formerly, I thought there was nothing that could be done about that other than turning off that behavior completely. However, recently while investigating another MapLibre bug, I found out that the thresholds for when a two-finger gesture is detected as either shove, rotate or zoom can be adjusted after all. They can be adjusted here: StreetComplete/app/src/main/java/de/westnordost/streetcomplete/screens/main/map/MapFragment.kt Lines 159 to 160 in 7c04687
The default values for the gesture detectors were (on my phone - not sure where/how they are set)
Would anyone who is interested in seeing this issue solved experiment with adjusting these thresholds so that it feels more natural and not prone to accidentally trigger the zoom gesture even though one wanted to trigger the rotate gesture (first)? (I'll open this for now based on the new information that the thresholds are adjustable) |
Even though you keep mentioning OrganicMaps as a source for this "feature", it doesn't change that allowing a rotate to start while zooming has been default in StreetComplete for ages. I still maintain that the default should be this, especially as its common that a combination of zooming and rotation is whats necessary to display quests hiden behind others and people are used to it. I beg you, at least consider making a setting "disallow rotation while zooming" or the inverse "allow rotation while zooming". Just consider that everyone with a opinion, even in the issue 3 years ago, has been in favour of making this a setting. |
Alright, I did experiment with changing the rotate threshold myself now. I did not find a threshold that would result in always doing what I wanted to do (zoom or rotate). Best value with lowest error was at about 1.5°-2° for me (default is 3°). Especially a sloppy rotation or rotation with zoom needed a really low threshold to always do what I wanted - too low for the zoom-only to always trigger when I wanted it to trigger. The other thing I tried out was to enable rotate while scaling but increase the threshold at which rotate gestures are detected from 3° to 5°. Didn't really work out. Accidental rotation while zooming was about as frequent as before plus there is a noticeable jump when it finally rotates the 5°+. Finally, I thought I should restore the behavior like in tangram again and tried it out a bit. In conclusion, I will just adjust the minimum angle for the rotate gesture to be detected to 1.5° (half that of the default) and leave the current behavior in place. Given that the people who were most annoyed about the new default behavior are not SC users anyway and there is already a ticket in SCEE to introduce a setting, I'll close this again. |
Comparison between version 58.2 and 59.0 alpha.
To make it clearer if needed: Both functions are working fine in v59 but not at the same time in the same gesture.
At least I find it difficult with only one hand to get the map to rotate first and then zoom, my mobile phone reacts to the zoom first in most cases with one hand. It works better with two hands.
(I took screenshots, but this is just a still and not helpful I guess.)
How to Reproduce
Expected Behavior
The map rotates at the same time as the zoom.
Versions affected
Version 59.0 alpha (SC and SCEE)
The text was updated successfully, but these errors were encountered: