Repository navigation
Pick up Labs.Notifications 12.1 and register the notification app id - #121
Merged
Merged
Conversation
Avalonia.Labs.Notifications 12.0.2 -> 12.1.0. Despite the name it is still built against Avalonia 12.0.1 and Tmds.DBus.Protocol 0.92.0, so it sits on Avalonia 12.0.5 unchanged (the DBus package still resolves to 0.92.0). It fixes three things this app runs into (AvaloniaUI/Avalonia.Labs#155, #158): - On Linux, clicking a notification never raised NotificationCompleted, because the portal only reports a body click when default-action is set. The update notification's click-to-download did nothing there. - On Linux, the icon was serialized as ((sv)) and the portal rejected it. - On macOS, denying notification permission crashed the app on the UserNotifications queue. It also adds AppNotificationOptions.AppId, which registers with the portal before notifying. Without it the portal infers the id from the systemd scope: empty when started from a terminal, the IDE's when started from one, and GNOME Shell then rejects the notification. It is set to DesktopEntry.AppId, the id the installed .desktop file and the GlobalShortcuts portal registration already use.
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
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.
This commit was meant to be part of #119, but it was pushed after #119 had already been merged, so it never reached master.
Avalonia.Labs.Notifications12.0.2 → 12.1.0, plusAppNotificationOptions.AppIdinProgram.cs.Despite the version number, 12.1.0 is still built against Avalonia 12.0.1 and Tmds.DBus.Protocol 0.92.0 (per its nuspec). It runs on Avalonia 12.0.5 unchanged, and the DBus package still resolves to 0.92.0. This doesn't unblock Avalonia 12.1: its
net8.0assembly still callsDBusConnection.AsConnection(). The note inDirectory.Packages.propsnow says so.From the release (#155, #158):
default-actionis set, and Labs didn't set it. So clicking the "update available" notification never opened the release page on Linux.SystemNotificationServicealready handlesIsActivated, so this needs no change on our side.((sv)), and the portal rejected it.AppNotificationOptions.AppId(Linux). It registers with the portal before notifying. Without it, the portal infers the app id from the systemd scope. That id is empty when the app is started from a terminal, or the IDE's when started from one, and GNOME Shell then rejects the notification.Program.cssets it toDesktopEntry.AppId, the id the installed.desktopfile and the GlobalShortcuts portal registration already use. If registration fails (older portal, missing desktop file), Labs ignores the error and behaves as before.Testing
dotnet buildis clean, anddotnet testpasses all 1215 tests.