Not working in Gnome 46 (Wayland)

[Barugon]

Notifications are not being displayed in Gnome 46. For example, This will print the NotificationHandle but no notification shows on the desktop:

    if let Ok(handle) = Notification::new().summary("Summary").body("Body").show() {
      println!("{handle:?}");
    }

[Barugon]

OKay, this seems to be an issue with Wayland. Works on XOrg.

[andymandias]

I believe I'm seeing this issue as well on Gnome 46 (Wayland) and was not seeing it in Gnome 45 (Wayland).

Oddly, the example programs provided with notify-rust that I've tried all work. For the notification sent by the application I'm working on, the notification sound is played but no notification appears in the notification center. The notification shows up in dbus-monitor, but it looks like it's immediately closed such that it never actually appears on screen.

Messing around with notification properties, I found that if I add an .on_close similar to the wait_for_closing example then the notification does appear.

[hoodie]

that seems like you have to keep the connection open then. If you don't use one of these to functions the dbus connection is tossed immediately.

[andymandias]

Still trying to track this down, as having the notification be open relying on the application being open (to keep the dbus connection open) is less than ideal (and isn't necessary for the examples). The simplest case I've been able to reproduce with is the following: open a window with winit's WindowBuilder::new().build(&event_loop) after which any notification (sent via the window event loop or not) will not show up on the desktop (but is visible via dbus-monitor).

One difference I'm seeing on dbus-monitor, but I can't tell if it's significant, is that notifications from other applications that are visible have both a sender-pid and x-shell-sender-pid dictionary entry, like

      dict entry(
         string "sender-pid"
         variant             int64 1779291
      )
      dict entry(
         string "x-shell-sender-pid"
         variant             uint32 1779291
      )

where the notifications from notify-rust only has a x-shell-sender-pid entry.

[andymandias]

Finally had some time to look into this further. I have not been able to able to find a way to get notifications to show from an event loop via XDG notifications. Adding the sender-pid to the dict doesn't help, nor any other way I tried to make the notifications match those sent by other applications or by utilizing libnotify. What I found to work, is sending the notification via XDG Desktop Portal notifications. The attributes/functionality is not one-to-one with XDG notifications unfortunately, but it does function.

If it's possible to augment notify-rust with XDG Desktop Portal notifications, would it be within the scope of the project? Not replace any existing functionality, but send portal notifications either when they are determined necessary. I'd be interested in working on that functionality, if it might have a place.

[kui04]

It seems the same problem in Gnome 46 (both X11 and Wayland)
tauri-apps/plugins-workspace#1562

[zeroskyx]

Issue appears to be tracked at the upstream repository with a potential workaround (--wait).

[lafleurdeboum]

I bump on the same issue here - with the test setup from tauri-apps/plugins-workspace#1562, I'm able to see the notifications appear and almost instantly disappear on app startup.

Would there be a way to use the --wait workaround in my tauri app ? Or does it mean it has to be integrated in the notifications plugin ?

[rickykresslein]

I have this problem when running via cargo run, but once I build and deploy a flatpak (not sure about any other packages or cargo build --release, haven't tested that yet) it works fine. Not sure if this is helpful, but it's worth a try.

[lafleurdeboum]

I just tried with yarn tauri build and then ./src-tauri/target/release/app, same behaviour - just even shorter appearance.

[Barugon]

Fedora 41 no longer includes XOrg, so this is a pretty big issue for me now.

[hoodie]

This sounds like several different options by now. From what I understand this seems to be because flatpak packages must use the desktop-portal in order to send notifications. As to why that results in them showing up for an instant only is still a bit confusing. Does anybody here have any other good hypothesis? I would welcome reproducers.

As for now, I would start by adding desktop-portal support. My initial attempts indicate that this is not too complicated, however the API is different enough to warrant some busy work.

Concerning the --wait functionality. Could somebody (maybe @lafleurdeboum) please elaborate on that? It seems a bit like a bad idea to block for notifications. But something that I have observed before on some desktop environments (they really all behave very differently) is that you have to keep the Connection open on some of them. The connection is held by the NotificationHandle, so please try if holding that improves the situation for you.

[Barugon]

Okay, I missed the comment above about the wait_for_closing example. Adding .on_close solved this for me.

[Barugon]

Okay, I missed the comment above about the wait_for_closing example. Adding .on_close solved this for me.

I spoke too soon. Using .on_close causes my process to hang until the notification is closed. Not good.

[hoodie]

That is what I meant.

[andymandias]

I put together a quick-and-dirty support for desktop-portal into a fork a while back (after I also found the hacks required for wait_for_closing to work as desired to be untenable). It did show notifications again, but the notifications were not being shown as originating from the application (from "Unknown App" instead, if I recall correctly). My unconfirmed suspicion was that something is off with how the application window is identifying itself with GNOME (via winit, in my case). Made sure everything matches with the .desktop as best I could tell, but that didn't help. Haven't had time to look for other reasons.

[Barugon]

If there were a way to simply check if a notification was closed (instead of having to wait for it) then that would be enough to work around this issue.

[hoodie]

I'm afraid there's just no API for that.

[djmaze]

If anyone is interested, until this is solved I built another workaround using the notify-send command (from libnotify). (I could probably have used libnotify directly, but the libnotify bindings for Rust seem outdated, so for now I implemented it like this.)

You need to use notify-rust from this branch with the notify_send feature (which is incompatible with the zbus and dbus features).

(I know this is not a full replacement. Also, hints and actions are not yet supported in my branch.)