feat(vibration): add global vibration pattern override for notifications and calendar#2
Merged
matejdro merged 1 commit intoMay 17, 2026
Conversation
…ons and calendar Adds overrideCalendarVibePattern field to NotificationConfig alongside the existing overrideDefaultVibePattern (notifications). CalendarEvent.toTimelinePin() now accepts an optional vibePattern parameter. PhoneCalendarSyncer resolves the configured pattern name via VibePatternDao and passes it when building calendar pins.
5 tasks
Owner
|
Any chance you can also upstream this to the core's repo? That way, this will be less of a maintenance burden as we will not have to constantly watch for this in merges. |
kchinnasamy
added a commit
to kchinnasamy/libpebble3
that referenced
this pull request
May 16, 2026
## Summary
Adds `NotificationConfig.overrideCalendarVibePattern: String?` to mirror the
existing `overrideDefaultVibePattern` (which covers notifications). When set,
the named pattern is applied to every calendar reminder synced to the watch.
Also adds an optional `vibePattern: List<UInt>?` parameter to:
- `CalendarEvent.toTimelineReminder(timestamp, pinUuid, vibePattern = null)`
- `CalendarEvent.toTimelinePin(calendar, supportsRsvpActions, vibePattern = null)`
Both default to `null` — existing callers are unaffected.
## Motivation
The notification path already supports a global vibration-pattern override via
`overrideDefaultVibePattern`. Calendar reminders are the other major surface
where a user might want to enforce a specific vibration style without per-app
or per-event configuration. The symmetric `overrideCalendarVibePattern` field
closes that gap.
`PhoneCalendarSyncer` is the only producer of calendar `TimelinePin` and
`TimelineReminder` items in libpebble3, so the wiring is contained.
## Implementation
Three files change:
- `LibPebbleConfig.kt` — adds one `String?` field to `NotificationConfig`.
- `CalendarEvent.kt` — `toTimelineReminder` and `toTimelinePin` both gain
an optional `vibePattern: List<UInt>?` parameter. When non-null, the
reminder / pin's attribute block appends `vibrationPattern { it }`.
- `PhoneCalendarSyncer.kt` — resolves the name in `overrideCalendarVibePattern`
to the actual pattern bytes via `VibePatternDao` and passes them to both
builders during sync. Also re-triggers a full calendar sync whenever the
config changes, via a `notificationConfigFlow.flow` collector with
`.distinctUntilChanged().drop(1)`, so an in-flight override change
immediately rewrites the existing pins on the watch instead of waiting
for the next event modification.
## Behavior notes
The watch fires the actual vibration from the `TimelineReminder`, not the
`TimelinePin` — but the pattern is set on both for consistency (the pin's
attribute is harmless when unused).
## Backward compatibility
Non-breaking. New field and params all default to `null`; callers that don't
set `overrideCalendarVibePattern` or pass `vibePattern` see no behavior change.
## Test plan
- [ ] Set `overrideCalendarVibePattern` to a known pattern name → next
calendar reminder on the watch fires with that pattern
- [ ] Unset the override → next reminder reverts to the bundled default
- [ ] Change the override mid-day → existing pins on the watch get rewritten
(validates the reactive re-sync collector)
- [ ] Leave the override null → behavior identical to before this change
## Context
Same change shipped on matejdro's microPebble fork as
matejdro#2. Upstreaming here so it lives
in coredevices/libpebble3 directly and matejdro's fork can drop the patch.
kchinnasamy
added a commit
to kchinnasamy/libpebble3
that referenced
this pull request
May 16, 2026
## Summary
Adds `NotificationConfig.overrideCalendarVibePattern: String?` to mirror the
existing `overrideDefaultVibePattern` (which covers notifications). When set,
the named pattern is applied to every calendar reminder synced to the watch.
Also adds an optional `vibePattern: List<UInt>?` parameter to:
- `CalendarEvent.toTimelineReminder(timestamp, pinUuid, vibePattern = null)`
- `CalendarEvent.toTimelinePin(calendar, supportsRsvpActions, vibePattern = null)`
Both default to `null` — existing callers are unaffected.
## Motivation
The notification path already supports a global vibration-pattern override via
`overrideDefaultVibePattern`. Calendar reminders are the other major surface
where a user might want to enforce a specific vibration style without per-app
or per-event configuration. The symmetric `overrideCalendarVibePattern` field
closes that gap.
`PhoneCalendarSyncer` is the only producer of calendar `TimelinePin` and
`TimelineReminder` items in libpebble3, so the wiring is contained.
## Implementation
Three files change:
- `LibPebbleConfig.kt` — adds one `String?` field to `NotificationConfig`.
- `CalendarEvent.kt` — `toTimelineReminder` and `toTimelinePin` both gain
an optional `vibePattern: List<UInt>?` parameter. When non-null, the
reminder / pin's attribute block appends `vibrationPattern { it }`.
- `PhoneCalendarSyncer.kt` — resolves the name in `overrideCalendarVibePattern`
to the actual pattern bytes via `VibePatternDao` and passes them to both
builders during sync. Also re-triggers a full calendar sync whenever the
config changes, via a `notificationConfigFlow.flow` collector with
`.distinctUntilChanged().drop(1)`, so an in-flight override change
immediately rewrites the existing pins on the watch instead of waiting
for the next event modification.
## Behavior notes
The watch fires the actual vibration from the `TimelineReminder`, not the
`TimelinePin` — but the pattern is set on both for consistency (the pin's
attribute is harmless when unused).
## Backward compatibility
Non-breaking. New field and parameters all default to `null`; callers that
don't set `overrideCalendarVibePattern` or pass `vibePattern` see no behavior
change. Source-compatible: existing call sites in the monorepo (`composeApp`,
`experimental`, etc.) that build calendar pins/reminders compile without
modification. Changes are confined to the `libpebble3/` module.
## Test plan
- [ ] Set `overrideCalendarVibePattern` to a known pattern name → next
calendar reminder on the watch fires with that pattern
- [ ] Unset the override → next reminder reverts to the bundled default
- [ ] Change the override mid-day → existing pins on the watch get rewritten
(validates the reactive re-sync collector)
- [ ] Leave the override null → behavior identical to before this change
## Context
Same change shipped on matejdro's libpebble3 fork as
matejdro#2 and has been running in the
wild via the matejdro/microPebble Android app, which surfaces it as a
user-facing global override in its Watch Settings UI. Upstreaming here so it
lives in coredevices/mobileapp directly and the matejdro fork can drop the
patch.
kchinnasamy
added a commit
to kchinnasamy/libpebble3
that referenced
this pull request
May 16, 2026
## Summary
Adds `NotificationConfig.overrideCalendarVibePattern: String?` to mirror the
existing `overrideDefaultVibePattern` (which covers notifications). When set,
the named pattern is applied to every calendar reminder synced to the watch.
Also adds an optional `vibePattern: List<UInt>?` parameter to:
- `CalendarEvent.toTimelineReminder(timestamp, pinUuid, vibePattern = null)`
- `CalendarEvent.toTimelinePin(calendar, supportsRsvpActions, vibePattern = null)`
Both default to `null` — existing callers are unaffected.
## Motivation
The notification path already supports a global vibration-pattern override via
`overrideDefaultVibePattern`. Calendar reminders are the other major surface
where a user might want to enforce a specific vibration style without per-app
or per-event configuration. The symmetric `overrideCalendarVibePattern` field
closes that gap.
`PhoneCalendarSyncer` is the only producer of calendar `TimelinePin` and
`TimelineReminder` items in libpebble3, so the wiring is contained.
## Implementation
Three files change:
- `LibPebbleConfig.kt` — adds one `String?` field to `NotificationConfig`.
- `CalendarEvent.kt` — `toTimelineReminder` and `toTimelinePin` both gain
an optional `vibePattern: List<UInt>?` parameter. When non-null, the
reminder / pin's attribute block appends `vibrationPattern { it }`.
- `PhoneCalendarSyncer.kt` — resolves the name in `overrideCalendarVibePattern`
to the actual pattern bytes via `VibePatternDao` and passes them to both
builders during sync. Also re-triggers a full calendar sync whenever the
config changes, via a `notificationConfigFlow.flow` collector with
`.distinctUntilChanged().drop(1)`, so an in-flight override change
immediately rewrites the existing pins on the watch instead of waiting
for the next event modification.
## Behavior notes
The watch fires the actual vibration from the `TimelineReminder`, not the
`TimelinePin` — but the pattern is set on both for consistency (the pin's
attribute is harmless when unused).
## Backward compatibility
Non-breaking. New field and parameters all default to `null`; callers that
don't set `overrideCalendarVibePattern` or pass `vibePattern` see no behavior
change. Source-compatible: existing call sites in the monorepo (`composeApp`,
`experimental`, etc.) that build calendar pins/reminders compile without
modification. Changes are confined to the `libpebble3/` module.
## Test plan
- [ ] Set `overrideCalendarVibePattern` to a known pattern name → next
calendar reminder on the watch fires with that pattern
- [ ] Unset the override → next reminder reverts to the bundled default
- [ ] Change the override mid-day → existing pins on the watch get rewritten
(validates the reactive re-sync collector)
- [ ] Leave the override null → behavior identical to before this change
## Context
Same change shipped via matejdro#2 and has
been validated through real-world downstream usage. Upstreaming here so it
lives in coredevices/mobileapp directly and downstream forks don't need to
carry the patch locally.
Author
created a new pull request with coredevices repo coredevices#193 |
matejdro
approved these changes
May 17, 2026
Author
|
@matejdro Sorry for the noob question, I thought we are waiting for upstream pull request to land, is this ok to merge this change to this repo, what happens when they accept upstream pr? |
Owner
|
No, we don't have to wait. But it makes it easier to merge future upstream changes, because branches will not diverge, once they also merge it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an optional
vibePatternparameter toCalendarEvent.toTimelinePin()andCalendarEvent.toTimelineReminder(), plus anoverrideCalendarVibePattern: String?field inNotificationConfig.PhoneCalendarSyncerresolves the configured pattern name viaVibePatternDaoand passes it to both pin and reminder builders, and re-syncs reactively when the setting changes.