MenuLayer: scroll wrap around & vibes

[MrXANA91]

This PR adds a scroll wrap around capability to the MenuLayer ui object, alongside some vibe functionalities.

23.12.2025_11.27.16_REC.mp4

New behaviors

Scroll wrap-around

Pressing the 'up' button when the first element of the MenuLayer is selected will wrap around and bring the cursor to the last element.
Pressing the 'down' button when the last element of the MenuLayer is selected will wrap around and bring the cursor to the first element.
However, wrap around will not be applied when holding down the 'up' or 'down' button, and cursor will still lock on the first or last element.

This wrap-around functionality is disabled by default but can be enabled with the menu_layer_set_scroll_wrap_around function.

Vibe on cursor blocked / vibe on wrap-around

A small 50ms vibe can be activated on wrap-around, or when blocked. Those two behaviors are mutually exclusive (setting one to true will set the other to false).

Those are also disabled by default, but can be enabled using the menu_layer_set_vibe_on_wrap and menu_layer_set_vibe_on_blocked functions.

Menu prefs

This PR also implements some new prefs to enable those new capabilties on every MenuLayer used accross the firmware system apps. No UI to change those prefs have been implemented in this PR though.

Here is a list of the apps affected

• notifications_app
• watchfaces
• alarm_editor
• alarms
• health_detail_card
• launcher_menu_layer
• send_text
• settings_system
• settings_window
• settings
• workout_selection

Known bug(s)

• Scroll wrap-around: if holding down the 'up' button when cursor is at the 2nd element, wrap around will still be applied. Same when holding down the 'down' button when cursor is at the penultimate element. <-- No longer observed with last build

Related issue(s)

Fix #414

[MrXANA91]

There might have been a better way to implement this, my first thought was to tinker with the MenuLayer internal iterator functions but I rapidly got the feeling that this wouldn't work easily. I instead went with a more brutal approach.

Known bug might not be that troublesome, leaving the decision to the Core Devices team if a fix is needed.
Known bug is coming from the is_repeating attribute of ClickRecognizer that is apparently malfunctioning. How hard would it be to fix it is unknown, but I think a quickfix from inside the MenuLayer code is possible.

Marking this PR as ready.

[jplexer]

I have one note, otherwise I am fine with this change though, well implemented!

[jplexer]

LGTM, but requesting review from Eric because it changes the menu behavior

[ericmigi]

I think someone will need to use this build for a week or two before we consider merging

[MrXANA91]

I think someone will need to use this build for a week or two before we consider merging

I assume you are talking about someone from Core or Rebble which makes sense.
I've sideloaded this version on my P2D nonetheless and will keep it at least until after new year's eve and give any feedback I have on here.

Happy Holidays! 🎄

[MrXANA91]

After actively using this build for around 2 weeks, here is my feedback :
For my personnal use, the wraparound is great, though it could deserve a vibe feedback when wrapping around or when stuck at the top or the bottom.
However, after some discussion in the discord, this behavior can be a deal breaker to some people.

I am converting this PR back to draft, so I can implement the following:

• System prefs for a completely configurable wrap-around behavior, which will be disabled by default to not break the current MenuLayer behavior (not wrapping around)
• System menu options to toggle those prefs (in the Display settings sub-menu? Or another custom sub-menu? TBD)
• Wrap-around implementation aligned on those prefs.

Edit: "system prefs" nnnnnope, I need to better understand how the settings are handled, I only knew about system prefs but they are for very specific global things, not the kind of settings I need here. I will probably call for some help on this, at least to understand the whole settings thing.

[ericmigi]

thanks so much for testing it so much and gathering feedback! I know it takes more work but it's really appreciated.

I think it would be best to keep it in draft until we can implement a system in mobile app for settings/prefs so we don't keep adding things to the watch side.

[MrXANA91]

I think it would be best to keep it in draft until we can implement a system in mobile app for settings/prefs so we don't keep adding things to the watch side.

I can still try to implement what I've planned and will keep the default behavior. But I completely understand the will to not bloat the firmware with every watch settings.
If it's okay, I can also enable the new behavior via a compile option, like I did in the Rebble version of this PR.

thanks so much for testing it so much and gathering feedback! I know it takes more work but it's really appreciated.

No problem! This is fun

[MrXANA91]

I've implemented everything I've said except the system toggle options in the UI. You won't be able to test those new functionalities without changing some default values in the menu_preferences.c source file, located here: src/fw/services/normal/menu_preferences.c.

I've also decomposed the different changes into three different commits for clarity.

I will test a special build that will allow me to toggle and tests those options on my watch, so I can again give some feedback. Requesting new review.

[jplexer]

Any reason why you created menu_preferences.c and didn't just include it in prefs.c?
Including it in prefs.c would allow us to really really easily integrate it into mobile settings once we ship that!!

[MrXANA91]

Any reason why you created menu_preferences.c and didn't just include it in prefs.c? Including it in prefs.c would allow us to really really easily integrate it into mobile settings once we ship that!!

I got scared by this comment in prefs.h:13, especially the last line:

// Shell Preferences
//
// These are preferences which must be available for querying across all shells
// and which must be implemented differently depending on the shell compiled in.
// Only preferences which are used by common services and kernel code meet these
// criteria.
//
// NEW PREFERENCES DO __NOT__ BELONG HERE WITHOUT A VERY GOOD REASON.

I felt like the new prefs I wanted to implement didn't really belong here. If you tell me that it would be better for everyone for those prefs to be here, I can do that.

[MrXANA91]

Force-pushed with the new implementation using prefs. This has been tested on a separate branch which adds UI menu to change those prefs.
Old implementation with the menu_preferences file has been saved in another branch if needed.

Requesting new review

[jplexer]

Awesome! We'll integrate this into the mobile app settings sync (soon!)