Settings: Add double click action settings

[faxe1008]

Listening to music while doing other stuff I wanted to have an option to skip songs. For convenience you'd need to have the watch on the music screen purposely run into the display timeout to change the music quickly without first navigating to the music app. It might be worth discussing if the double click action is not a concrete "next" action but rather a "jump to X" action.

One thing that I did not change (although might be desirable) is that if the watch has the "Audio Next" action selected to not wake up the display controller. Feel free to comment :^)

[github-actions[bot]]

Build checks have not completed. Possible reasons for this are:

1. The checks need to be approved by a maintainer
2. The branch has conflicts
3. The firmware build has failed

[faxe1008]

@JF002 whats your oppinion on this feature? I'd love to have this in the official FW.

[JF002]

I understand that a lot of users would like to have more settings and options so they can customize InfiniTime for their own specific use cases.

But this is not an easy task in InfiniTime mostly because of the very limited resources (adding settings and features cost memory) and the small display. A while ago, we wrote the InfiniTime Vision document where we describe some core principles and vision that we want to apply to the project. One of those core principles is "Prefer solid default experience over customization" : we do not want to add settings and options for each and every functionality. We instead prefer to implement a simple unique behavior that will work for most of the users.

I'm sure that some users would appreciate the double click action to go to the next song... while other would like to do something else. And we cannot support each and every use-case in our tiny firmware.

Also, please keep in mind that all applications are now optional : they can be enabled/disabled at build time, and we need to ensure that InfiniTime works correctly even if some applications are not built into it. This PR adds a dependency between the "core" InfiniTime and an optional app, which is something that we should try to avoid.

[faxe1008]

@JF002 Thanks for your detailed response. I agree with every point you made. I wonder if we can have both, a rock solid firmware that is considered the release artifact but also give a good amount of customization for people willing to hack/compile on their own. The feature of this PR might be a bit more involved, but I also in the past needed to maintain a patch of my own to adjust the vibration duration of the alarm app for example. Being able to make little tweaks like that would be amazing. I'd love to see broader use of a configuration "framework" of sorts, be it a header file or Kconfig. I know that this will increase maintenance on the project and complicate CI, since all sensible configs need to be build. What is your oppionion on that?

[JF002]

Something we'll probably do at some point in the future is to add a configuration API which would allow companion apps to set all the settings using BLE. Companion apps have much more richer UI and bigger screens and they'll be able to provide a much nicer experience to the users. This way, we'll be able to add new settings in InfiniTime without having to add a new Setting application.

Another thing we could do to help with those little tweaks you maintain in your own fork would be to add "read only" settings (constants) and to provide an easy way to change their default value at build time. This could be used to specify the vibration duration, the number of notifications, colors of the theme etc.

[faxe1008]

If anyone also wants this feature I have rebased against current develop. Feel free to cherry-pick it. @JF002 thanks again for discussing the issue of customization. Is there already a PR on the way for adding a setting header of sorts? If not I'd love to take a stab at it.