-
Notifications
You must be signed in to change notification settings - Fork 282
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
Keymapper phase 2 enhancements #243
Conversation
Next up
|
Okay so how I've merged keymapper = new L.DistortableImage.Keymapper(map,img., {
position: '' //keymapper not rendered
}); |
Open to other ideas regarding merging both these params, else I guess maybe we can proceed with this? |
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.
@rexagod
Ok so looking over this I am wondering about a few things. We might want to set up a time to Zoom to go over it if you'd like.
My main question is why make the keymapper extend the handler class? I see that it gives us the ability to choose whether the keymapper is placed on the map or not depending on whether we leave the line keymapper.enable()
uncommented. But I don't see how this is different from having the keymapper extend L.control
, and in the index.html
file initializing it just like this:
new L.DistortableImage.Keymapper({position: 'bottomleft'}).addTo(map);
and commenting that line out if you don't want to have the keymapper on the page. This takes care of the position
problem if we just add an L.setOptions(this, opts)
to its initialize
function.
We would have to get rid of the keymapper: false
option for now but I think thats fine. If we really wanted to we could move this option to work with the keymapper
class.
I was also unsure about its functionality because I found that after the keymapper is initially enabled, running keymapper.disable()
does not remove it from the map, as img.editing.disable()
removes the markers and toolbars from an image.
Would love some insight here because I could be misunderstanding the point! Also I think @jywarren initially suggested used L.handler
. Was there a specific reason for that?
@sashadev-sky I've noted your suggestions and will chime in a bit after I wrap up the CLI tool if it's not a problem? Thanks! |
Oh this looks good! Thanks! If this is getting ready for a merge and
release, let me know but if it'll be another little while, we could
consider just using an "x" button, what do you think?
…On Sat, May 25, 2019, 3:42 PM Pranshu Srivastava ***@***.***> wrote:
@sashadev-sky <https://github.com/sashadev-sky> I've noted your
suggestion and will chime in a bit after I wrap up the CLI tool if it's not
a problem? Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#243?email_source=notifications&email_token=AAAF6JYRME2WWWYBOJQSE4TPXGI6TA5CNFSM4HKUZDD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHX7CI#issuecomment-495943561>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAF6J6FM2KUXYM6HT4D65TPXGI6TANCNFSM4HKUZDDQ>
.
|
Okay, no problem, and just to be clear, where should I place this 'x' button? Do you think that maybe we should use a fontawesome icon inside the button above (replace 'disable keymapper' with 'x' icon) or is there any particular position that would make more sense? |
Yeah, a fontawesome icon sounds... awesome! And yeah, I guess upper corner
would be perfect. Thanks!
…On Sat, May 25, 2019, 3:55 PM Pranshu Srivastava ***@***.***> wrote:
Okay, no problem, and just to be clear, where should I place this 'x'
button? Do you think that maybe we should use a fontawesome icon inside the
button above (replace 'disable keymapper' with 'x' icon) or is there any
particular position that would make more sense?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#243?email_source=notifications&email_token=AAAF6J46DKWMBF24OQNCSXDPXGKQ7A5CNFSM4HKUZDD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHYFPI#issuecomment-495944381>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAF6J4NWCTIBZTMXXI3NZTPXGKQ7ANCNFSM4HKUZDDQ>
.
|
@jywarren How does this look? |
Hmm. I guess his response here should definitely pave the way for this PR. Pinging @jywarren.
@sashadev-sky |
I'm fine with splitting things out, but had asked @rexagod to prioritize
the "close" button because it's causing some difficulties in live
MapKnitter.org. Thank you!
As to handler... gosh, i feel like it was a million years ago. I honestly
don't remember, but if you can pull the link to the comment i can try to
catch up on it?
…On Wed, May 29, 2019 at 5:27 PM Pranshu Srivastava ***@***.***> wrote:
Would love some insight here because I could be misunderstanding the
point! Also I think @jywarren initially suggested used L.handler. Was
there a specific reason for that?
Hmm. I guess his response here should definitely pave the way for this PR.
Pinging @jywarren <https://github.com/jywarren>.
I was also unsure about its functionality because I found that after the
keymapper is initially enabled, running keymapper.disable() does not remove
it from the map, as img.editing.disable() removes the markers and toolbars
from an image.
@sashadev-sky <https://github.com/sashadev-sky> disable() seems to work,
or am I running a different use case scenario?
[image: test]
<https://user-images.githubusercontent.com/33557095/58592544-52545d80-8286-11e9-9fd5-614884abe05f.gif>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#243?email_source=notifications&email_token=AAAF6J3BO5UE77LVWDPFQYDPX3YIRA5CNFSM4HKUZDD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQWA5A#issuecomment-497115252>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAF6J4IOLFZKDHDJT3BYNTPX3YIRANCNFSM4HKUZDDQ>
.
|
@jywarren #212 (comment) I think it might have been on accident you suggested but I could be wrong! @rexagod hmm I think what I was referring to was that if you try to use disable() later on, like in the console perhaps, it doesn't disable the keymapper like it would with the handles. If there isn't an identifiable benefit to making it in a handler class that then call the control class to create it, should we just refactor to make it control class like in my suggestion above? |
I just turned off the keymapper in MapKnitter briefly until we get the "many keymappers appearing" and "ability to close keymapper" resolved: #243 Thanks! I also thought we ought to make it not /ever/ open a 2nd keymapper, does that make sense? Awesome! |
That should relieve pressure on this PR so we can take a bit more time to get it right. Thanks, all! |
Aha! So, in #212 (comment), I meant that we could give it its own namespace, /like/ the |
dist/leaflet.distortableimage.js
Outdated
L.DistortableImage.Keymapper = L.Control.extend({ | ||
initialize: function(options) { | ||
L.Control.prototype.initialize.call(this, options); | ||
L.DistortableImage.Keymapper = L.Handler.extend({ |
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 here, yeah - sorry, we don't need this to extend Handler
- that was just a fragment of the code i was quoting. I mainly meant just putting this all in L.DistortableImage.Keymapper
- which looks great!
Sorry, clarifying further re: Handler, i put an inline comment at #243 (comment) |
@jywarren @sashadev-sky Okay so I've added the aforementioned changes to this, while holding on to the Handler -> Control one, for the following reasons.
Therefore, I didn't see any benefit from the refactoring, so I thought of discussing this out first. But I can be wrong, and thus ask your views on the same. Thanks!! |
Also, I'm currently using Handler wrapper class just for the above mentioned functionality it provides, while the actual keymapper is implemented in var keymapper = L.control({position: this._position});
keymapper.onAdd = function() {
var el_wrapper = L.DomUtil.create("div", "l-container");
el_wrapper.setAttribute('id', 'keymapper-wrapper');
el_wrapper.innerHTML = "<table><tbody>" +
"<tr><td><center><span id='keymapper-heading'>Keymappings</span></center></td></tr>" +
"<tr><td id='keymapper-hr'><hr></td></tr>" +
"<tr><td><kbd>j</kbd>, <kbd>k</kbd>: <span>Send up / down (stacking order)</span></td></tr>" +
"<tr><td><kbd>l</kbd>: <span>Lock</span></td></tr>" +
"<tr><td><kbd>o</kbd>: <span>Outline</span></td></tr>" +
"<tr><td><kbd>s</kbd>: <span>Scale</span></td></tr>" +
"<tr><td><kbd>t</kbd>: <span>Transparency</span></td></tr>" +
"<tr><td><kbd>d</kbd> , <kbd>r</kbd>: <span>RotateScale</span> </td></tr>" +
"<tr><td><kbd>esc</kbd>: <span>Deselect All</span></td></tr>" +
"<tr><td><kbd>delete</kbd> , <kbd>backspace</kbd>: <span>Delete</span></td></tr>" +
"<tr><td><kbd>caps</kbd>: <span>Rotate</span></td></tr>" +
"<tr><td><center><button id='close-keymapper-button'>" +
"<kbd id='close-keymapper-kbd'>" +
"<i class='fa fa-times-circle' aria-hidden='true'></i>" +
"</kbd></button></center></td></tr>" +
"</tbody></table>";
return el_wrapper;
};
keymapper.addTo(this._map); |
@rexagod I am going to pull this and rebase you because you've been out of the repo for a bit and then I will go over it! |
7e2dc43
to
a1b3002
Compare
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.
The new look is awesome, @sashadev-sky! Congrats on fixing the Travis build, too! It can sure be quite frustrating at times!
LGTM! 😃🙌
Fixes #239
Make sure these boxes are checked before your pull request (PR) is ready to be reviewed and merged. Thanks!
grunt
If tests do fail, click on the red
X
to learn why by reading the logs.Please be sure you've reviewed our contribution guidelines at https://publiclab.org/contributing-to-public-lab-software
Thanks!