-
-
Notifications
You must be signed in to change notification settings - Fork 860
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
Fix gray borders #1211
Fix gray borders #1211
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me on Web. I note that the map can no longer scroll horizontally infinitely, which might be important to some people - see #1201?
Fair point (assuming you mean the extra wrap or whatever its called as opposed to infinite, I think infinite will need a separate "fix" in general). |
In that case, I'm happy for you to merge this 👍 |
Works great. Excellent work @ibrierley! |
@JaffaKetchup I just tested it a bit further what happens normally, with the extended pan. I think you can only get to see those extended east/west parts if you have a grey border at the top/bottom. So I think this is as ok as it probably can be for the moment. So I think let's merge this as it's an added feature and shouldn't affect existing uses, and if we come along to things like getting infinite scroll, or someone has some other related issue around this, we can try an adapt. I do think your point about that is relevant |
@ibrierley I'm just updating the documentation. What is the difference between |
Weird, it was working earlier, I tested it. Now I can't get it to work, even checking out earlier versions from ages ago, so think I'm missing something. I'll try and debug this eve if I get chance. (I note mapController bounds example works, but the map options feels broken or something). |
Or was I testing maxBounds, and mapOptions bounds hasn't worked for ages. It will be good to try and figure this out anyway. |
Interesting. Just wondering though, what should the difference be? They sound like they'd do the same thing. |
Yeah, I think |
Just did a bit of digging. Basically, bounds is making the map initially fit to those bounds. I.e to focus on an area (but not restrict) like London. Ideally it should be called fitToBounds or something, it will create the lowest zoom and center to fit in those bounds....and doesn't currently work(with our examples anyway), I wonder if anyone uses it :D. (Note it works in the mapController params). I'd be interested to know if anyone does use it. maxBounds forces the map/tiles not to go outside of the area of those bounds. So you could set it to LatLngBounds(LatLng(-90,-180),LatLng(90,180)) and it will make sure the users visual area doesn't go outside of those bounds to prevent a grey area, or smaller bounds to restrict to a more specific localised area (eg London), so you could never view any other area outside of it. I think the problem with bounds/fitToBounds on the Map side (and why mapController bounds works), is that when the map is initialised, it has no valid widget size (but it does a moment later), so it tries to figure how to fit the map into those bounds, but as it has no size to calculate from, it produces garbage which is later rejected. As mapController normally takes a short while to sort itself out, it can probably get a valid widget size by the time it runs and works. We can fix it if wanted, but I don't like this fix really (happy to be convinced otherwise!), maybe as it feels like its in the wrong place or something..but feels like it should be fixed by widgets, not staged checked code....
If that is plopped into flutter_map_state.dart and called inside the LayoutBuilder, eg...
I wish I could figure a more elegant solution, but my brain isn't very good with delayed widget sizes and stuff. It's possible it currently works for some people who have a tightly controlled widget sizing, and our examples in a Column confuses it at first, as I think that can cause sizing issues at first (again, I don't know enough on the intricacies of nested widget sizing) . |
I see. Maybe for the moment we'll just leave it broken (or you can apply your patch). Really some work needs to be done on making It's up to you, but I'll just open an issue for now to make it known. |
We use |
@stx How do you specify it's sizing? @ibrierley mentioned that it might happen depending on how it's laid out ( |
@JaffaKetchup We use it many ways - Expanded() within columns on mobile app screens, fixed width/height on web, etc. - works great everywhere. |
Hmm. @ibrierley did you have the code snippet you tested it with? |
If it helps, here's the helper function we use to specify the LatLngBounds:
|
I just tested it with the examples home page. One thing as mentioned I dug out, was that certain outer widgets can cause issues, like Columns which the examples use (hard to know if thats relevant here). I tried to add an Expanded widget which one SO answer to a similar problem suggested, but that was outside the Layout builder which may not help. It could be, try it without our examples, that it works ok...but either way, I don't really like a solution that isn't solid for a user in all cases if that makes sense (we've had enough grief with mapController bugs :D). |
This introduces a maxBounds parameter (I believe leaflet.js uses this param, so tried to be consistent with naming). This will take a LatLng Bounds object, and try to make sure that the map display area isn't outside the bounds.
It will try and "adjust" to the nearest edge point, rather than just failing, to allow smoother dragging if it would otherwise be too small.
Use LatLngBounds(LatLng(-90, -180.0), LatLng(90.0, 180.0)) if wanting to contain the full map, and have no gray borders, otherwise a smaller area to contain.