-
-
Notifications
You must be signed in to change notification settings - Fork 866
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
Proposed fix for unsymmetrical anchored markers disappearing #1291
Conversation
I will enter one more commit. There is an error |
Even after the commit, my markers are disappearing. I will investigate a little more... |
Ok friends. I fixed the math and tested it. flutter_map_marker_hide_fix.mp4 |
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.
Haven't had time to test, but I note there's a typo in "right vs rigth"
I always confuse them :) nice catch |
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.
So, coordinate systems headache incoming, related to yesterdays comment :D
Are we sure 0,0 is bottom/right ? That sounds totally odd. (This isn't your fault btw, original is like this), but I can't work out if it should be different or not, I think it does work with it all swapped around).
Eg Why is sw.x larger than ne.x ? I feel like some stuff is still reversed :D so I'm finding it hard to approve this change when my spider sense is tingling.
I am sure that for Anchor coordinate system, the (0,0) is bottom right. When I printed these values, I saw that Anchor.left is 113 when the width is 149 Similarly Anchor.top prints 0 and the anchor is on the bottom of the Marker
|
@ibrierley for the namings, I agree with you. They can cause confusion. Would this make more sense? (I swapped left/right and top/bottom) This way sw and ne makes more sense
I feel like, whatever we change, it will still not make too much sense because we are dealing with 2 different coordinate systems in the same code snippet. Map coordinate system having (0,0) at top-left and Anchor coordinate system having (0,0) at bottom-right @JaffaKetchup I know you are busy with the exams. But can you at least confirm this is the case with the coordinate systems? And good luck with the grades ;) |
(btw I'm away from tomorrow for a few days, and as Jaffa may be busy, it might be a case of revisiting next week, I suspect I don't have any issue at all with the fix, just maybe it needs some extra code docs or something) |
@ibrierley ok, let's look at this next week. I would be more happy too if everything is perfect and up to standard. Please let me know if any changes are needed and have a nice time. |
@aytunch |
Yeah I would agree. Using top left as (0, 0) definitely makes more sense. Whether we want to make as big of a breaking change as this is a different question. |
Interesting, just found this.... |
Actually, that may not be relevant thinking about it.... |
@ibrierley Nice find from 2018 :) |
I think it is related. But the author only cared about the vertical convention not the horizontal |
Yeah, and don't worry, I won't be suggesting any breaking changes at all short term (one could conceivable consider your fix very slightly changing in behaviour if they've coded some hack workaround, so we probably need a minor release, but I doubt anyone ever has hacked around it). My main concern with this type of stuff is making sure any "oddness" gets documented in the code (and main docs for usage), so there's as easy logic as possible (partly as people often reuse code later on), that way next time, any devs don't spend too long on it iyswim. |
We should definitely state in documentation https://docs.fleaflet.dev/usage/layers/marker-layer#markers-markers that;
|
I'll try to have a look at this today if possible. |
Hi @JaffaKetchup @ibrierley how are you guys? I was using my PR in the production app and everything was fine for disappearing markers. Meanwhile, if you know a way to use this PR in dependencies along with clustering plugin, it would help me out a lot too. video from the attached cluster issue: spider_disappear.mov |
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.
Sorry for the slow reply @aytunch, totally my fault, keep saying I'll do it, then I never do.
By just looking at the code and the videos, I can tell it will work, and as it's a simple change, I don't feel the need to test it - we can always revert if absolutely necessary.
Note that it may take a while for the version to become available on pub.dev, unfortunately. This is because I need to write the CHANGELOG for the version, which needs approval and merging.
In the meantime, you may try using 'dependency_overrides'? |
@JaffaKetchup there is no fault. We are very thankful to both of you for developing and maintaining this awesome package and your personal plugins as well. As for the changelog, maybe something along these lines might be enough
Who does the approval and merging btw? |
Thanks :) CHANGELOG should be simple enough, but there are some other changes to put in there from previous commits. If I submit the CHANGELOG PR - which is annoying at the moment, as I already have a fork for #1294, so I'll have to get involved with Git ( |
I see. Good luck with #1294 |
Hey, always glad to have a new user! Happy to answer questions. Heads up, please use the v5 branch, or pub.dev prereleases. There are lots of breaking changes to get from v4 to v5, so there's no point implementing it. |
@aytunch Just thought I should quickly mention, I just broke the v5 branch (see JaffaKetchup/flutter_map_tile_caching#44 (comment)), so use the pub.dev pre-releases which still work. Also avoid using background downloading until the next pre-release - I'm changing it a lot. |
@ibrierley @JaffaKetchup please check and see if there is any hiding happening with your working projects.
Thank you very much for the discussion.
Fixes #918.