Notification actions/callbacks

[hkparker]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

Notifications right now just display a string, and on mobile you don't appear to be able to click them to enter the app. On many mobile applications, clicking notifications not only opens the app, but opens it to the context / feature of the app relevant to the notification (think how clicking the notification of a chat app takes you to the specific conversation thread that created the notification).

I'd like to be able to send notifications with Fyne that, when the platform allows for it, let the user click the notification and enter the app with context.

Is it possible to construct a solution with the existing API?

Not that I'm aware of

Describe the solution you'd like to see.

notification := fyne.NewNotification("Title", "Content", func() {
    // This notification was clicked, now I can take some action and/or display the relevant container in the app
})

[Jacalz]

This is a great addition. However, do keep in mind that modifying the NewAnimation function when implementing this would be a breaking change. It would have to be part of the struct and maybe in a separate fyne.NewAnimationWithCallback function (or similar).

[andydotxyz]

I'm not sure it can be done with functions, though it would be nice if that was possible.
I think the lowest common denominator to notifications would be entering the app through a deep link... but this task needs real investigation to learn what is possible before we put an API on it.

[hkparker]

I'd imagine something like this for the API side of that

myDeepLink := url.Url{} // url that should be used to call into the app when the notification is clicked
notification := fyne.NewNotificationWithDeepLink("Title", "Content", myDeepLink)

myapp.SetDeepLinkHandler(func(deepLink url.URL) {
    // match the URL to a rule and do anything / display anything as needed
})

With this scheme the developer gets to provide their own function for matching any deep link, which is very flexible

[Jacalz]

I think a field of some kind on the notification struct likely will be the best option. Some kind of map[string]func() might work. I have the Linux side of portal.NewNotification wrapped up and ready to use when we implement this

[andydotxyz]

On many mobile applications, clicking notifications not only opens the app

Reading this again I think that point could be easier - we could register a fallback fyne handler with the app ID as some key parameter (part of scheme maybe?) to reference the app without needing any new APIs or handlers,

[theHilikus]

I would love this functionality in Windows as well, but with the option to support more than 1 action in the notification since a notification could have 2 buttons, each triggering a different action, think "launch" and "ignore". It sounds close enough to not warrant a separate ticket. My workaround for now was to integrate a separate library to handle windows notifications but it would be great if fyne could take care of even "enhanced" windows notifications with buttons and support them in any platform that allows is

[Jacalz]

FWIW: Anyone can do this on Linux specifically already using https://github.com/rymdport/portal. The Linux part of this implementation will this be easy to do be just using those APIs once this is implemented.

[andydotxyz]

FWIW: Anyone can do this on Linux specifically already using https://github.com/rymdport/portal. The Linux part of this implementation will this be easy to do be just using those APIs once this is implemented.

Can you point more specifically? I can only see Icon and Title, and to my awareness the DBus notifications API used does not support more...

[Jacalz]

Can you point more specifically? I can only see Icon and Title

Oh, sorry. I thought I had implemented all of the notifications protocol but it looks like it was the filechooser protocol that I had implemented. I'll get that sorted.

, and to my awareness the DBus notifications API used does not support more...

The old DBus protocol like does not but the portal API definitely supports it. See API reference: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Notification.html

[andydotxyz]

Thanks for the clarification. I see now there is a whole other DBus API for the portal notifications.

I guess that we will have to implement both and then the actions can be added only if the portal API is the one available?

[Jacalz]

I guess that we will have to implement both and then the actions can be added only if the portal API is the one available?

Likely, yes. Although, it is also worth checking out to which degree it is common for Linux distributions to not support portal API nowadays. They have existed for many years and essentially become the standard thanks to the push from Flatpak.

[andydotxyz]

I’m trying to get info on that but it seems only Gnome and KDE have full support with many (90%) partial support. What I can’t easily tell is which parts are in or out. According to ChatGPT summary the GTK shim used by the others doesn’t support the full actions, just the “default action”. The summary I got is: “If you’re writing a sandboxed Flatpak or Snap app and need interactive notification buttons today, you can rely on them only when the host desktop is GNOME 46+ or KDE Plasma 5.26.5+ / 6.x.”

…

On 5 Jul 2025 at 20:28 +0100, Jacob Alzén ***@***.***>, wrote: Jacalz left a comment (fyne-io/fyne#4953) > I guess that we will have to implement both and then the actions can be added only if the portal API is the one available? Likely, yes. Although, it is also worth checking out to which degree it is common for Linux distributions to not support portal API nowadays. They have existed for many years and essentially become the standard thanks to the push from Flatpak. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>