Closed modos189 closed 5 years ago
Maybe you'll be able to finish options.padding support. Ornaments are constantly shifting: either by moving the map or changing the screen size
Ornaments are constantly shifting
We need padding to solve this, or this issue caused by unfinished padding support?
It's not ready. Maybe I should have sent it to a separate branch. Padding is needed to draw portals that are outside the visible part of the screen, but close to it, just like in Leaflet and IITC. I have implemented this, but there are some conflicts when moving the map. Ornaments move more than portals.
As this feature is not blocker it makes sense to put it separate branch.
And tell me more about 419b1ab: what is 'atypical use'?
I was able to fix it. Padding works correctly.
what is 'atypical use'?
Our code tries to remove those markers which may not exist.
That's why I added additional checks to correct the errors.
I was able to fix it. Padding works correctly.
Great! But check upper comment please ^^^:
Our code tries to remove those markers which may not exist.
removeMarker
was broken anyway.
Also I am going to fix our code, so we do not need additional checks in upstream.
Although, those checks may make sense in general (but not in this branch).
@modos189 I am going to clean up and rewrite this branch, tell me when you ready. Separate branches for all features already created (todo: a52cbaf383b38e1c642bc5d4e34ae399688e8ba5)
Please check comments regarding padding option.
I have implemented fixes in padding-option
branch, but not tested yet.
My fault, thank you for pointing out.
I saw you similar change in padding-option
branch. But there is an error: instead of layerPointToContainerPoint
you should use containerPointToLayerPoint
I saw you similar change in
padding-option
branch
I've just updated that branch with your last commit. Let's continue padding-related development there.
As all needed for IITC features are now separated between own branches, all we need - merge them together, like this:
git checkout master
git checkout -b changes-for-IITC
git merge --no-ff fixes canvas-resize layer-features-back padding-option
git push --force
I've already done this in test
branch, and about to rewrite changes-for-IITC
branch with the content of test
.
All future updates should go to feature branches, here we'll need merge them together only.
P.S. And I suppose we need to open corresponding PR's in Spaction's repo.
@modos189
I finished with all branches except padding-option
.
I am unable to check it, as I just do not understand how it should function. Let's start from related issue: https://github.com/IITC-CE/ingress-intel-total-conversion/issues/184
It's all working now.
@modos189 I am not sure that 2 latest commits are needed. See test branch (as I said in previous message)
In https://github.com/IITC-CE/ingress-intel-total-conversion/pull/181 which branch is being used? I used that version and I thought it was from test branch
up: Indeed, these changes already exist in the test branch
Do you still need this branch? If not then I will rewrite it with actual commits.
No, you can rewrite
I'm totally confused in branches, so I created a new branch for onresize method: https://github.com/IITC-CE/Leaflet.Canvas-Markers/tree/onresize
Merge after this: https://github.com/IITC-CE/Leaflet.Canvas-Markers/pull/1#issuecomment-489002729
I'm totally confused in branches
We have independent branch for every new feature here. We keep it so it will be easy to make PR's to parent repo in the future.
And all that branches merge together here, in changes-for-IITC
- it is not independent branch.
So to complete our work here we should finish last branch, for what we have concerns: padding-option
.
I think it is not ok, check comments for f451114f2f74e9cd896cd8a160e3d34bffdcc7ff
@johnd0e 1d88dcf
Good! But see question there.
Also question about _updateTransform
left unanswered in https://github.com/IITC-CE/Leaflet.Canvas-Markers/commit/f451114f2f74e9cd896cd8a160e3d34bffdcc7ff
On one hand, this change is specific to IITC, and on other hand - for greater similarity with the leaflet. Perhaps we should create a parameter to determine whether the container should be destroyed. See: https://github.com/IITC-CE/Leaflet.Canvas-Markers/commit/b6c228a1b1752255c6b82be3c91473fc02b578af