Skip to content

Pick up Labs.Notifications 12.1 and register the notification app id - #121

Merged
vesnicancz merged 1 commit into
masterfrom
chore/labs-notifications-12.1
Oct 26, 2026
Merged

vesnicancz merged 1 commit into
masterfrom
chore/labs-notifications-12.1

Conversation

@vesnicancz

Copy link
Copy Markdown
Owner

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.Notifications 12.0.2 → 12.1.0, plus AppNotificationOptions.AppId in Program.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.0 assembly still calls DBusConnection.AsConnection(). The note in Directory.Packages.props now says so.

From the release (#155, #158):

  • Linux: clicking a notification now works. The portal only reports a click on the notification body when default-action is set, and Labs didn't set it. So clicking the "update available" notification never opened the release page on Linux. SystemNotificationService already handles IsActivated, so this needs no change on our side.
  • Linux: the notification icon is accepted. It was serialized as ((sv)), and the portal rejected it.
  • macOS: denying notification permission no longer crashes the app. The crash was a segfault on the UserNotifications queue.
  • New 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.cs sets it to DesktopEntry.AppId, the id the installed .desktop file and the GlobalShortcuts portal registration already use. If registration fails (older portal, missing desktop file), Labs ignores the error and behaves as before.

Testing

  • On current master: dotnet build is clean, and dotnet test passes all 1215 tests.
  • The changes are Linux/macOS runtime behaviour, so tests don't cover them. Worth trying on Linux (GNOME ideally, started from a terminal): a Pomodoro transition notification should appear with an icon, and clicking the update notification should open the release page.

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.
@vesnicancz
vesnicancz merged commit 4003e25 into master Oct 26, 2026
2 checks passed
@vesnicancz
vesnicancz deleted the chore/labs-notifications-12.1 branch October 26, 2026 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant