I’ll confess that I haven’t seen that issue on my phone. I do know that when I delete the postprocess.sh script from my home directory it no longer can save picture for some reason(I had a postprocess script from syncing my homedir from mobian on the pinephone).
I’ll look at --raw option, thanks!
Sadly the main camera hasn’t been working for a couple of weeks for me (while the selfie camera does work). I did have a working script before that. (My script is a lot more basic than yours. The sole goal of my script was QR code for COVID check-in.)
Gotcha, I hope purism fixes that soon!
Based on your suggestion, I’m considering writing up a gui that:
After that create a separate program that’s intended to offer the ability to turn various types of data into qr codes via plugins. Examples of plugins I’m thinking of:
Thoughts?
I think you should be, and will be, praised for your effort, is what I think.
I’m wondering if it would be beneficial for usability to have it work so that the reading ability will be in both, as now via Megapixels and can be separate As in, basic reader ability and the the other stuff as well via GUI.
The history option sound neat. From usability perspective, it would be nice to have a “re-do last code” button vs. “open list & copypaste”, if that’s not too much. On the other hand, there may be a need to edit the text (perhaps a typo in the original) before use/launch, as well as a need to turn that edited text to a new qr - close to what you have already in the plan.
If you’re looking for features to add, how about an optional visible/readable text below or besides the code. For instructions or content description or for and advert (maybe an optional default text) etc. It would save from copypasting the qr to an editor. Definitely something for later stages of development.
About the other plugins, I’m thinking those in terms of an easy way to transfer info (especially in a way that is pretty private and safe, if it’s via the phone camera from the screen of a friend or yourself). Especially strings that need to be correct (yes, like wifi pw etc.). How about a method of relaying the info for a quick access to shared screen or setting up shared secrets or relaying GPG? Custom codes sound good - could your app help set it up as a process, where a custom prefix could launch a designated app with the data or some other action(s)? One common one would be sharing contact details but there are several options: the plain text (with a nice layout - same row or stacked) or one of the virtual calling card standards.
And what about adding an encryption to the text? A bit overboard, but a simple pw mechanism might be useful for some. For a more advanced usecase, the pw could be replaced with location - as in: vicinity needed to open the qr (to prevent/inconvenience global use).
I think there will be limits that will be met and your GUI could help tell how much text/data can be crammed into the qr vs. size, or whether it would be smarter to think making the qr a link to the large text/data/file/object.
I hope these keep you busy. There are probably suporterts for a sleek, minimalist version as well.
If that means that the Librem 5 is configured as a hotspot and it is displaying a QR code so that clients can connect to the Librem 5 as hotspot then I wouldn’t bother with implementing that because the Librem 5 can either already do that or will be able to do that.
On the other hand if that means that the Librem 5 is configured as a WiFi client and it is displaying a QR code so that other would-be WiFi clients can connect to the same WAP that the Librem 5 is connected to then beware the security issues but OK.
If you are going in the direction of creating QR codes then I would suppose that for starters you should have GUI to solicit the information needed to create a valid QR code for each of the types of QR code that you support scanning of. (That would be without plugins and definitely before getting to custom QR codes.)
In other words, right now you have decode of: mailto, mecard, geo, tel, smsto, http, https
So I am suggesting that you add encode of those options.
And also add decode and encode of wifi:
Business card QR codes come in two overall types, web links (URLs) and real business cards, and within the latter type they come in various formats. For example, I just picked one web site at random and their business card decodes as BEGIN:VCARD …
Aside: Web link business cards look like the latest privacy scam from the web. I’m not suggesting that a site offering such a service is actually a scam but I can see where that would be going … (if anyone wants to pursue that comment, please fork the topic)
There are no real standards for most of this.
See also an earlier discussion starting at Camera development progress
That earlier discussion mentions sms:
PS I would change the match of http* to separate matches of http and https because you don’t really know what the future might bring for other schemes whose name starts with http, and any given user of your script may not be sufficiently knowledgeable to know whether such a future scheme is safe.
Note thattmy current vision is that there would be a separate app from megapixels for the history and whatnot. For the history:
Didn’t think about the editing though. I’ll need to think about that. Will need to be careful to not make that too easy though lest people mess up their codes. Perhaps only the ‘saved codes’?
Indeed, those sounds like good plugins. I’m going to start small though(very few plugins to start), and my hope is to make plugins easy enough to write to encourage people to write their own personal one, or contribute them to let others use them.
Current thought process for plugins is just a directory that would house scripts (each script being a plugin) and I would just take any stdout and qr codify it (assuming it returned 0). Hopefully that would make it really easy for others to write their own.
That’s part of the idea behind the “Provides the ability to add/modify actions for how to handle different types of qr codes”
Yes, that’s the idea behind that one. The security issues I can see with that are:
I’m not sure I follow, but I do agree that documentation is needed. Largely at present I’m trying to pull in the existing standards.
You’re absolutely right. I need to be a little less lazy there.
Not that I can think of. Those were the basic points that I had in mind. Any time you are messing around with security-relevant info, it is a good idea to consider the “what ifs”.
You will need sudo and that makes it all the more fraught (even though needing sudo is obviously a good thing).
Out of the box, user purism is set up with sudo access without entering a password (so sudo will work regardless of whether it is a good idea). However I have changed my phone to require a password (and that could in theory break some scripts).
Sorry for the stream of consciousness. The basic point is that, as a starting point, whatever you can decode you should be able to encode, where “encode” is referring to that separate program that you were talking about to create QR codes.
So for example if you have code to take an smsto: QR code image, decode the QR code into the embodied string, then pick out the destination phone number and message (then actually offer to send that text message) then …
the reverse process would be code to
By the way, are your delimiters correct for smsto: handling in the decode? From what I’ve seen, the format is
smsto:optional-phone-number:optional-message
and the optional-message may include the colon character (so programmer beware).
So smsto:: is valid (when scanned would launch the program to send a text but neither the phone number nor the message would be prepopulated) and smsto::: is valid (phone number not prepopulated and message prepopulated with a single colon character). Yes, these are extreme cases.
One other comment: Per RFC 1738, schemes are supposed to be recognised without regard to case. So you ought to be standardising the case for comparison purposes but you must not standardise the case of the entire URL. So the easiest approach may be to extract the scheme (assumption is that everything starts with a scheme followed by a colon character), downcase it, and then compare only against lower case. Or, even easier, use the nocasematch shell option (untested by me).
I am definitely seeing QR codes where the scheme is in unexpected case so this is not a theoretical comment.
Ok I believe all of the mentioned issues should be fixed now.
How do you have a qr code scanner when the rest of us don’t have a camera app? last I checked with the latest developments on Librem5 software?
megapixels is the current camera app. Purism has slowly been getting the camera to work better and better. Granted a few phones have issues like irvinewade’s.
Purism didn’t make megapixels, but it is available for install from their software app. It’s been used on the pinephone for some time now for picture taking.
To be exact, Megapixels used on the Librem 5 is a heavily modified, forked version that uses different V4L API, removes features that are not relevant with our sensors and adds some that are not relevant to PinePhone’s ones.
Currently the selfie cam should reliably work for everyone (at least on Dogwood batch forward, not sure about the earlier ones), while the rear cam depends on your luck. On one of my phones it works perfectly (see https://social.librem.one/tags/shotonlibrem5 
), on other one it’s capricious, and on another one it’s basically unusable. This should improve with further work on the driver.
Note that megapixels has had QR code scanning built-in for a little while now, and it works out of the box for the pinephone.
Indeed it does! It’s good to see. Though I wonder why pureos doesn’t support it at this time?
Granted the ability to save, and set custom actions for qr codes would still have value. As well as the ability to share things are qr codes.
Definitely.
Given that a QR code can mean just about anything, customisation by the user is essential to
Per the classification from @dos, mine (main cam) is currently in the category of “basically unusable” even though previously it seemed to be in the category of “works perfectly”. Looks like software “unpredictability” and I will be waiting for driver updates. Selfie cam continues to be reliable. (It has become academic for me anyway, being in lockdown, as you don’t need a mobile phone if you can’t go “mobile”. I assume eventually we will transition back to the previous situation, where a working QR code scanner is almost a legal requirement - and I will again be keenly awaiting a working main cam.)
The Librem 5 branch/fork is based off a earlier version that didn’t support QR code scanning. I’m certain that their changes will be upstreamed eventually.
Custom actions can be done using a protocol handler, see https://askubuntu.com/questions/514125/url-protocol-handlers-in-basic-ubuntu-desktop.
… although Megapixels as installed on the Librem 5 highlights the QR code as if it is detecting it and as if it might do something with it. Perhaps there is incomplete work-in-progress code for QR code scanning.
That could be something but in my case I wanted to make the handler for http: dependent even on the domain in question.
Also, a customer may want to disable a protocol as accessed via QR code scanning but not disable it completely.
So I think there’s still plenty of scope for user configuration.