Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working in Gnome 46 (Wayland) #218

Open
Barugon opened this issue May 3, 2024 · 4 comments
Open

Not working in Gnome 46 (Wayland) #218

Barugon opened this issue May 3, 2024 · 4 comments

Comments

@Barugon
Copy link

Barugon commented May 3, 2024

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
Copy link
Author

Barugon commented May 3, 2024

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

@Barugon Barugon changed the title Not working in Gnome 46 Not working in Gnome 46 (Wayland) May 3, 2024
@andymandias
Copy link

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
Copy link
Owner

hoodie commented May 16, 2024

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 added a commit to andymandias/halloy that referenced this issue May 17, 2024
…t user interaction if `on_close` is called on the `NotificationHandle` (related issue: hoodie/notify-rust#218).  This adds a noop `on_close` to ensure that doesn't happen, but it prevents Halloy from closing until all notifications are dismissed.
andymandias added a commit to andymandias/halloy that referenced this issue May 17, 2024
…t user interaction if `on_close` is called on the `NotificationHandle` (related issue: hoodie/notify-rust#218).  This adds a noop `on_close` to ensure that doesn't happen, but it prevents Halloy from closing until all notifications are dismissed.
@andymandias
Copy link

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 have a a x-shell-sender-pid entry.

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

No branches or pull requests

3 participants