refactor binary branding mechanism to use qmake/qml
after qt merge (#295 (closed)), it is simpler if the branding mechanism can change to happen in the frontend layer.
I think the simple transition path is to generate a pre-seeded providers.json that we pass to Qml (which can be used also for the provider selector), and include here also the variables that we're including in pkg/config right now. Maybe in different files so that we do not mix the bonafide-format and the more internal variables for the binary. Then we can initialize the backend with that data (name, urls, donation needed, and ca certificate basically).
Branding itself can now be made with qmake - I guess we can define the path to the assets in a relative way - and passing a custom folder to the build. Ideally, this folder would be self-contained - and can be managed in a separate repo. As I see it, this would be everything that the vendor needs to keep up-to-date for being able to produce a custom build (libraries, calyx).
Maybe a helper script can be added - at least to validate that the configuration folder has everything needed. It would be sweet if it can also generate derived assets from, ie, an svg, but that's a further sophistication.
There are some corner cases that I still don't see how to fit - for instance, the snap/debian packages still will need some of the templating dance that we're doing right now. But still, those packages can benefit from a refactor that implies passing a single external repo as the authoritative source of all the customizations.
-
pass branding folder for assets -
pass binary name on build time -
initialize backend with all the configured options -
deprecate old-style vendoring