This needs validation testing with Gramps 6.0 on macOS and a Linux box.
Just discovered a problem with the drag scrolling of Maps on Windows. I think it might be due to an unintended increase in the number of zoom levels between Gramps 5.2 and 6.0 versions. The mouse interface breaks at the new levels.
But it needs to be tested on the other OSes.
Tests were performed with 3 mapping services and 3 view modes. All had the same the symptom. So lets test using example.gramps file. In the “Geography: Show all places” view with OpenStreeMap service, choose “Show all places” from the context menu. Zoom all the way out and then all the way in on a Marker.
In 5.2 at maximum zoom (100m/100yd scale), the left-drag correctly shows a filtered Events and Places context menu related to the indicated map pin. If no marker is indicated, then left-drag scrolls the map.
In 6.0 at maximum zoom (20m/80ft scale), the left-drag incorrectly shows ALL Events and Places context menu, losing the context of which map pins are nearby. So scrolling the map with the mouse not possible. If you zoom out 1 level, it starts working again.
In Gramps 5.2.2 on fedora, the tiles are stored with sub-folders labeled 1 to 18 for each service in .gramps/maps/openstreetmap
In Gramps 6.0 on Windows 10, the tiles are stored with sub-folders labeled 1 to 19 for each service in C:\Users\test\AppData\Local\Microsoft\Windows\INetCache\gramps\maps\openstreetmap
Some services (like GoogleHybrid) store 2 extra levels (labeled 1 to 20) and both the extra levels exhibit the problem.
There are hundreds of sets of the following 3 lines of warnings reported to the console too:
Thanks for checking that. Could you post the path to the map tiles on macOS and verify the labeled folder range in its OpenStreetMap subfolder?
I think that we may need to to add purging the map tile cache when doing an update. The folder path seem to vary between versions. So old, unused tiles might consume a LOT of storage space.