InfiniTime

InfiniTime copied to clipboard

I am opening this issue as a general discussion about customization. We have the problem that InfiniTime wants to keep unnecessary customization out in favor of good defaults, but we also have a user base that seems to like to tinker on a lot of little details. Both are completely valid. I do not think that "maintain your own fork" is a good default solution for this.

I propose the following three tiers of customization:

1. Settings that can be changed via the UI, because people actually change them on a stable setup (like turning Bluetooth off).
2. Settings that can be changed from the settings file via BLE FS without a UI, so not everything needs a UI. This would need changes on the file and maybe the companion apps. People could share those config files with each other. An example could be custom vibration times/patterns.
3. Custom builds, for everything that needs no runtime configuration, like which apps, watch face or general features to include. I am also thinking of something like building the firmware completely without heart rate monitoring for people who are not interested in this.

For 2 there is also another way: instead of requiring the companion app, there could be a "secret" config screen like Firefox's about:config with very spartan design, basically just a long list of toggles or radio-groups, or something even more primitive.

This under-the-hood config screen should not be easily reachable by mistake by novice users, e.g. hidden behind long pressing on the last page of the firmware infos, or some other konami-code-like swipe/button-press combo.

@ght I like your idea a lot. Reminds me of the developer settings in android. So maybe a hidden setting that can be enabled by clicking multiple times on the about screen.

In my opinion point 3 is doable by using something like kconfig files in the cmake frame (Like ESP-IDF).

The next step is that all components will setup by an automated process. If this works a new app or feature can be maintained in a submodule and will add by the cmake/kconfig process

I did a successful test in #1296 and if anyone from the project is actually interested in this, yours sounds cleaner regarding the cmake part and we should have a look at it.

I will take a look at this. The biggest work will be to change the main structure to use all component and screens as own libs and link them only they are used.

I will do a POC in the next weeks

The main thing that needed my code generation script was the order of apps in the app menu. I followed the order of the apps as given in the config file. I don't know if this is possible with CMake.

There you're right. CMake can't insert code snippets to add the apps. But the KConfig things can be use as defines in the source code. Then we don't need an additional script. (I think so :-D)

If we reorganize the components/Apps/Screens as small libs with own cmake files we can force the compiler to don't build this, if they don't needed. This will be the cmake part. But I'm not Sure if the work worth it

This would at least reduce the amount of work the Python script has to do. We could maybe keep the part with the app order. Let's see if the core team has any interest in this subtractive approach.

This sounds like a great idea (I was just searching for any discussion about how to handle settings now that we have ble FS access). There's a PR for saving settings out as CBOR at #1070 which might be useful - it feels like it's a bit too hard-coded for the "known" options though, so might need to be more a generic settings service that the various parts register their settings into. (I'm thinking in scope of only settings, app optionality would probably happen on top of whatever settings thing gets done).

Perhaps the build system could create a json file (or yaml or whatever the cool kids are using these days) that describes the settings that the build supports, their valid values, help descriptions etc, and it puts that json file into the resources. Infinitime when running saves and loads settings from/to a cbor file on littleFS. The app would not interact with the json at all.

So the littleFS would have:

F:/settings.dat - CBOR representation of the running watch's settings
F:/settings.json - static json created by build system, describing setting structure

A python tool in the repo (and/or a companion app, say) could read the json and cbor files, build a gui using the constraints specified by the json file and populate it from the cbor values, allowing the user to (moderately) safely edit those settings.

This way the firmware doesn't need to have a pile of metadata baked into it describing and validating all the settings, and companion apps don't need build-specific knowledge about valid settings (or their ordering) outside of parsing the json file that was prepared by the build system. It also means the documentation for settings gets put into the code itself. Users can back up their settings and companion apps might even manage migrating settings between versions.

Ultimately (and this is getting a little off-topic and I don't know if it's feasible) I think it'd be great if we had the ability to build the firmware with all apps classed as either built-in or modular, with built-in apps statically linked into the main dfu image as done already, and modular-tagged apps being put into the resources as binary blobs, which the watch could load dynamically (ie, copy into ram for execution) based on an app-list setting. Each binary blob would have its own dat and json file for its settings. I don't know if this is practical on the nrf52 or not, my c++ knowledge and google-fu are both letting me down on that :-)