Hajk
Hajk copied to clipboard
QrCode - a little investigation
Someone had the idea of adding a qr-code option for print in kommungis. The idea is to have an option for generating a qr-code here:
The option would be initially turned off, as to not overlap with logo, scalebar and north arrow. If turned on, the warning for overlapping icons would work the same, of course.
If chosen correctly, however, the qr-code would appear like this:
The qr-code is implemented by using QrCode from "qrcode
.
Link to library: https://www.npmjs.com/package/qrcode
And a possible logic for this in PrintModel
would be this:
generateQR = async () => {
try {
const url = AppModel.anchorModel.getAnchor2();
return await QRCode.toDataURL(url);
} catch (err) {
return "";
}
};
if (options.includeQrCode) {
try {
const qrCodeImageData = await this.generateQR();
let qrCodePlacement = this.getPlacement(
options.qrCodePlacement,
20,
20,
dim[0],
dim[1]
);
pdf.addImage(
qrCodeImageData,
"PNG",
qrCodePlacement.x,
qrCodePlacement.y,
20,
20
);
} catch (error) {
// The image loading may fail due to e.g. wrong URL, so let's catch the rejected Promise
this.localObserver.publish("error-loading-qr-image");
}
}
However, in testing this, I encountered many problems with generating and updating the url. The AppModel.anchorModel.getAnchor()
is not enough for correctly generating a updated url with every layer and and zoom an so on. I guess you would have to copy much of the logic from Anchor
to keep it updated.
I'm not sure what the best solution is. Further investigation is needed.
In conclusion, I would say this is a cool feature that is possible to implement. But, the question is if it's worth the trouble. Perhaps not.
Great idea.
I would suggest we use the functionality added in #1252 for this. Start by enabling enableAppStateInHash
in all your maps (it's an Admin setting). (Ideally, in future releases, this will be made the default functionality. I'm open for enabling it by default. It's stable, we've been using it for 6+ months in production.)
With that enabled, you generate the QR code by taking the current value from window.location.href
. That's it. 🚀
Awesome! Thanks. I'll take a look at it.
Den tis 3 okt. 2023 kl 11:04 skrev Jacob Wodzyński @.***
:
Great idea.
I would suggest we use the functionality added in #1252 https://github.com/hajkmap/Hajk/issues/1252 for this. Start by enabling enableAppStateInHash in all your maps (it's an Admin setting). (Ideally, in future releases, this will be made the default functionality. I'm open for enabling it by default. It's stable, we've been using it for 6+ months in production.)
With that enabled, you generate the QR code by taking the current value from window.location.href. That's it. 🚀
— Reply to this email directly, view it on GitHub https://github.com/hajkmap/Hajk/issues/1407#issuecomment-1744543351, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2VNYU4YCQWPBNDRHZFAQ5LX5PIJ7AVCNFSM6AAAAAA5QSVGBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUGU2DGMZVGE . You are receiving this because you authored the thread.Message ID: @.***>
I think it would be worth the trouble, QR-codes are cool!
I read this again and saw this from your initial post:
However, in testing this, I encountered many problems with generating and updating the url. The
AppModel.anchorModel.getAnchor()
is not enough for correctly generating a updated url with every layer and and zoom an so on. I guess you would have to copy much of the logic fromAnchor
to keep it updated.
Are you sure about this? I had a look at this and the getAnchor
method does take all the map View's parameters into account, as well as layers (including group layers), plus current query string in search box, currently visible plugins and current CQL filters (which nobody seems to use anyway 😉).
What else do you need? 😄
Yo yo! Im back, and here's a little update on qr code:
Turns out the enableAppStateInHash worked perfectly. Me and Jesper talked about checking for this value to be true before enabling qr code client side. Otherwise it doesnt work with simply using the updated url.
Welcome back! 😄 As for enableAppStateInHash
, I have a feeling that this will sort out itself in a moment. We're about to merge some client-related changes into develop
and I'd propose that we change Hajk's default behaviour to be enableAppStateInHash=true
anyway. We've been using it for a couple of years now in production so it's quite battle-tested. @Hallbergs and @jesade-vbg, opinions?
Thanks! Good to be back :) Maybe we dont need to check for enableAppState then?
I think it's still a good idea to check, just as it's currently done elsewhere, see e.g. https://github.com/hajkmap/Hajk/blob/1087aaaa2df1a0697c9b84e7277513cd5c12ee4b/new-client/src/components/App.js#L576.