Projekte / user-notify
Warum noch ein Notification-Crate?
Ich habe das während des DeltaTauri-Ports gebaut. Für einen Messenger müssen Benachrichtigungen mehr können als nur Text anzeigen - ein Klick auf eine Benachrichtigung muss den richtigen Chat öffnen, nicht nur das App-Fenster. Man braucht auch das programmatische Entfernen von Benachrichtigungen per ID (z.B. wenn eine Nachricht auf einem anderen Gerät gelesen wurde), Inline-Antworten und Action-Buttons.
Tauris Notification-API unterstützte damals nicht einmal Grundlagen wie Click-Handler oder das Entfernen von Benachrichtigungen per ID. Die vorhandenen Rust-Crates, die es intern nutzte, hatten auf manchen Plattformen die gleichen Lücken. Keine der Alternativen deckte alle drei Betriebssysteme mit allen Features ab, die wir brauchten.
Community-Interesse
Ich habe die Bibliothek zunächst als Teil der DeltaTauri-Codebasis gebaut und als Workaround im Tauri-Issue-Tracker gepostet. Community-Mitglieder baten mich, es als eigenes Crate zu extrahieren, damit auch andere es nutzen können.
Hey @Simon-Laux, I tried your crate on OSX and it works well thank you for sharing. Do you have any plan to extract it as a standalone crate?
Architektur
Jede Plattform hat eine eigene, von Grund auf gebaute Implementierung:
- macOS - nutzt objc2, um Apples UNUserNotificationCenter-API direkt aufzurufen.
- Windows - nutzt das windows-Crate für Toast-Benachrichtigungen.
- Linux - nutzt derzeit notify-rust, wird aber wahrscheinlich auf direkte D-Bus-Aufrufe umgestellt, um bestehende Bugs zu beheben. Ich habe auch mit ashpd (Flatpak-Portal-API) experimentiert, das vielversprechender ist, aber eigene Probleme hatte.
Plattform-Eigenheiten
macOS war knifflig: Objective-C-APIs aus async Rust mit Main-Thread-Anforderungen aufzurufen führte anfangs zu einigen Abstürzen, aber mittlerweile läuft es echt stabil.
Linux ist nach wie vor am herausforderndsten. Verschiedene Desktop-Umgebungen, die Aufteilung zwischen der klassischen D-Bus-API und der Flatpak-Portal-API und mein begrenztes Verständnis der D-Bus-Interna bedeuten, dass es noch Bugs zu beheben gibt - das ist Work in Progress.
Windows hatte seine eigenen Herausforderungen: Die Dokumentation kann ohne Vorerfahrung mit Windows-APIs schwer zu folgen sein. Aber jede Plattform ist belohnend, wenn es schließlich funktioniert. Der ganze Sinn ist es, anderen zu erleichtern, gute Benachrichtigungen in Rust umzusetzen, ohne über diese Plattform-Details nachdenken und drei verschiedene Implementierungen pflegen zu müssen.
Einsatz in Delta Chat
Delta Chat Desktop (Tauri-Edition) nutzt user-notify für alle Benachrichtigungen: Nachrichtenvorschau mit Bildanhängen, Gruppen- und Kontaktavatare und das direkte Antworten aus Benachrichtigungen auf macOS.
Dasselbe Feature wäre auch unter Windows möglich, ist dort aber wegen offener Sicherheitsfragen noch nicht aktiviert1. Persistente Benachrichtigungen funktionieren ebenfalls korrekt: Ein Klick darauf, nachdem die App geschlossen wurde, öffnet sie an der richtigen Stelle wieder.
Status
macOS und Windows funktionieren gut. Linux hat noch einige Bugs (siehe den Issue-Tracker für Details). Ich plane, user-notify weiter zu pflegen, und das ist ein weiterer Grund, warum ich es in ein eigenes Repo extrahiert habe. Die DeltaTauri-Edition ist noch experimentell, daher gibt es noch keinen hohen Produktionsdruck, aber die Bibliothek ist auf macOS und Windows solide.
Wenn Sie ein bestimmtes Feature brauchen oder die Entwicklung unterstützen möchten, melden Sie sich gerne: git@simonlaux.de.
- Unter Windows funktionieren Benachrichtigungs-Antwort-Aktionen über Custom-URI-Deeplinks. Wenn die App nicht läuft, könnte ein Browser oder ein anderes Programm einen Link erstellen, der die Antwort-URI fälscht und das Senden einer Nachricht auslöst. Wir haben das in Delta Chat deaktiviert, bis wir eine Lösung finden. Siehe deltachat-desktop#5134.