This removes the dependency on the QrEncode lib and uses
the fact that our scanning lib also is capable of making QRs.
We now allow the QR to get its color inverted for dark mode
users, making it less bright to show a QR.
This introduces a new QR-creation mode which allows spaces and
other chars to be in there directly without being URL-encoded.
This improves the QR showing of the user's seed-phrase (in the
backup screen).
This adds the ability to scan a seed phrase with your camera by
adding a button to the wallet import page.
This also adds support for the QR format that the bitcoin com
wallet uses in its QR for seed phrases.
This sets up a basic system for creating modules on top of the flowee
pay static lib in a way that is ensured to be isolated (modules can't
accidentally use each other's classes)
The setup is made such that the buildsystem does the hard work on
plugging in a new module, making it so that all you need to do is create
a new dir and a "{something}ModuleInfo.h" file and it will get compiled
in.
The point there is to make it not have any merge conflicts and just make
it dead easy to get started.
Yesterdays refactor causes the OS defines to only be specified for the
shared library. This makes the app-specific compiles receive the define
again too.
Slowly the amount of cpp sources has been growing to the point
where its just too much to store in the root of the project.
I think they are more happy in a subdir as well, getting an elevated
position for themselves.
This allows a developer to avoid including the headers file in the APK
so it becomes a lot smaller and deployment is faster.
This only works on reinstalls, it won't be able to run on a phone where
Flowee Pay has never been installed.
After working on android and the qtmultimedia library for a week,
I have a much better understanding of what works and what doesn't.
The resulting design is thus presented. We will have one
CameraController class which refers to one overlay panel in QML
and in different places in the GUI objects based on QRScanner
can be created to initiate a scan.
This additionally moves the actual scanning out of the GUI thread
since blocking that is a no-no.
Now to move towards actually supporting scanning usecases.
This takes the camera feed and pipes it through the ZXing (pronounced
zebra-crossing) library which detects the barcodes in the image.
When we find it, we pluck out the text.
Learned the trick to getting the version set and now printing it again
also use it to only include the private stuff in the versions of Qt
that we need to use the private headers.
For doing dirty stuff, I just always want to have a sunsetting defined
to avoid us silently depending on it forever.
This makes it possible for the mobile app on Android to use the camera.
We only ask for permission when the user actively goes to the 'QR-Scan'
tab, and we show a simple preview of the camera feed.
Notice that the permissions stuff is quite ugly right now due to Qt
having that module in development and the public APIs are simply not
available yet. But at least it works, which is all that matters.
When the next minor Qt release comes out we can hopefully clean this
up and use a version that needs no ifdefs.
When doing development on Android we don't really have a good way to see
what is going on or run a second application showing the log-lines. So the
simplest solution is to just use what we already have in Flowee: a logging
system with pluggable channels.
Now, we only want this during debugging, so this is a CMake option
and the file is compiled and included only when you set that.
Additionally, the code won't do anything unless there is a config file
included in the APK (assets dir) with the host etc.
The usage of the big application singleton for enums is not the best for
linkage.
See, in QML you like to use enums, but you need to register the object
it is defined on with QML. So, you ideally have one object with loads of
enums. Easy to maintain, less to learn for the QML author.
Using the application-wide singleton made kind of sense, but this
creates a dependency requirement for all users of these enums that
doesn't jibe well with maintainable code.
So, introduce a simple enums-only class that can be used from QML and is
cheap to include from any using classes.
To solve this becoming slowly unreadable due to ifdefs, move stuff to
methods which have a differnt implementation based on which OS we target.
The build-system now chooses to compile only the utils file for the
target OS.
This alters the build setup to create two executables based on
practically the same CPP static lib but with different QML
dirs and translations.
This also adds a cmake option
-Dlocal_qml=ON
when passed it will create an executable that will load the QML
from local disk instead of using the compiled-in version.
The main advantage of that is that there is no need to recompile
after each QML change.
To avoid recompiles and such generally to simplify stuff, this
moves all the code into a static lib that is then linked with
by the various apps (including tests).
tomFlowee