draft: macOS notification integration

[Rello]

• Adds actionable macOS Notification Center notifications for Nextcloud server notifications—the same notifications shown under the web UI bell and desktop tray “Notifications” section.
• Exposes supported server-provided actions in macOS, including Dismiss.
• Propagates native dismissal back to the Nextcloud server and removes the corresponding tray entry.
• Adds inline replies for Talk notifications when a message ID is available; otherwise opens Activities.
• Routes notification clicks and actions to the correct account in multi-account setups.
• Reconciles delivered and pending macOS notifications with the latest server notification list, removing stale entries.
• Keeps notifications visible and actionable in the existing tray menu.
• Extracts notification handling into a dedicated, account-scoped module under [src/gui/notifications], replacing the former systray-specific macOS implementation.
• Shares preview text and action metadata between tray and native notifications.

creates with GPT-5.6 Sol

[claucambra]

We already have the capacity to emit interactive macOS notifications via UserNotifications in the systray code, why not take this and repurpose it? Seems like it would avoid some duplication here

[Rello]

We already have the capacity to emit interactive macOS notifications via UserNotifications in the systray code, why not take this and repurpose it? Seems like it would avoid some duplication here

is ist not not using the existing one? the issue with the current one was, that it did not have a unique id, so be able to perform an action across many accounts.

The shared notification logic for all platforms was moved into [src/gui/notifications] to make the code modular like the other recent refactors.

• NotificationManager: fetching, filtering, deduplication, tray population, action dispatch, dismissal and platform selection.
• ServerNotificationHandler: server notification retrieval.
• NotificationConfirmJob: execution of server-provided actions.
• TalkReply: sending Talk replies.

Only the native presentation layer is platform-specific:

• macOS uses MacNotificationCenter in the same module.
• Linux and Windows continue through the existing Systray::showMessage() path—Freedesktop notifications on Linux and QSystemTrayIcon otherwise.

if i misses something, let me know

[i2h3]

This fails to build for me.

src/gui/notifications/servernotificationhandler.cpp:99:85 calling 'toArray' with incomplete return type 'QJsonArray'

Besides, I am skeptical about the priority of this and also do not feel good about the platform-specific feature duplication for a little more fancy user interface. 😕(more than the new menu bar extra) While the horizontal action stack does not even look that good.

[i2h3]

Review: macOS native notifications

Thanks for this — the direction is solid and pulling the notification logic out of User/UserModel into an account-scoped NotificationManager is a real improvement. Notes below; nothing here is a safety bug, and the two most important items are UX/product questions rather than change requests.

What's good

• Clean separation: NotificationManager (fetch → dedup → present → dispatch) vs the thin MacNotificationCenter façade; User/UserModel shrink nicely.
• Stable, content-addressed notification identifiers (NextcloudServerNotification-<sha256(accountId:id)>) make proper remove/reconcile of delivered banners possible — something master couldn't do.
• Per-notification responseActions in userInfo keyed to a shared, signature-derived category is a correct design (links are per-notification; categories dedupe by action shape).

I looked specifically for threading / lifetime / memory-safety issues and found none: callbacks marshal back to the main thread via performOnMainThread/performWithNotificationManager, the account registry uses QPointer, reconciliation is generation-guarded, and the manual retain/release is correct for this MRR (no-ARC) target.

Two questions to settle before merge (inline on macnotificationcenter.mm:590 and notificationmanager.cpp:285):

1. Clearing/swiping a banner now issues a server DELETE (removes it on all devices) — intended?
2. First fetch fires one banner + sound per pending notification instead of master's aggregated toast — aggregate above a threshold?

Cleanup (inline): dead macOS TALK_MESSAGE path, the platform-split gating in buildNotificationDisplay, the never-pruned category registry, and a sendTalkReply DRY nit.

Pre-existing (carried over from master, not introduced here — just FYI): canSendNotification() is still a TODO stub returning center != nil; requestAuthorization() is called on every send; and the ETag short-circuit in servernotificationhandler.cpp (if (!_preFetchEtagHeader.isEmpty() || …)) is effectively inert because _preFetchEtagHeader is always empty on a per-fetch handler. Probably a separate cleanup ticket.

[i2h3]

FYI: I let Claude Opus 4.8 Ultracode review it (as explicitly requested by @Rello), I did not write the comments above myself.

[Rello]

I propose grouping of the notifications. @i2h3 ok or not a good idea for any reason?

• Calls → one stack per account
• Talk → one stack per conversation and account
• System news/announcements → one stack per account
• Files and sharing → one stack per account
• Everything else → one “Other” stack per account

[i2h3]

@Rello sounds reasonable.