dunst VS mako

OS: Arch Linux WM: Qtile Panel: Qtile bar Launcher: Rofi Notification Daemon: Dunst Terminal: Alacritty Shell: Zsh Compositor: Picom File Manager: Nemo Music Player: Spotify & ncmpcpp

https://github.com/dunst-project/dunst is a pretty popular notification daemon that comes to mind.

Notification : dunst

Your notifications are not provided by Plasma, but by dunst. Either you installed dunst yourself or something else you installed is dependent on dunst.

Are you running something able to act on notification requests from programs, e.g. dunst (which is what i use)?

OS: Arch Linux WM: Bspwm Compositor: Picom Launcher/Powermenu: Rofi Status Bar: Polybar Terminal: Alacritty Shell: Zsh Editor: Neovim Notification: Dunst File Manager: Lf PDF Viewer: Zathura Text fonts: JetBrains Mono Nerd Font DOTFILES: here

Here's the documentation to create an asynchronous monitor with pyudev. When a device is plugged in, use subprocess to run notify-send and send a notification through dunst with the proper parameters (search "do_action" in the dunst docs), so for example you can bind your left click to mount and your middle click to mount and open

The notification in your screenshot looks like dunst. Removing that notification server should bring back the default notifications by Cinnamon's own notification server (which, AFAIK, is built-in).

You can use dunst for notifications, minimal and lightweight. I use it for my volume and brightness control along with sxhkd. dunst Hope this helps.

So, using this github issue as a reference, I'm trying to make a wofi menu that appears when a bluetooth file transmission is sent to my PC from my phone (or any other device for that matter).

I currently use mako for the notifications. When I play Strategy Games (Mouse is all over the place) and a notifcation pops up, the mouse gets stuck on the notification message until I click it.

I use avizo as a volume indicator, mako for notifications generally.

I guess some standard notifications app like https://github.com/emersion/mako doesn't suffice, as it isn't related to a window?

mako is a Wayland notification daemon from one of the principal Sway/wlroots devs, and is currently provided with openSUSEway. It's pretty minimalist, but so are most things in the Sway/wlroots ecosystem.

It's a notification, I use mako: https://github.com/emersion/mako

Notifications: mako

Is there any way to force dbus to use a specific notification daemon? On one of my systems, I run both Plasma and Sway. The latter obviously doesn't have a notification system, so I'm using mako. As far as I can tell, mako automatically launches when a notification is fired, however this causes an issue with Plasma. Plasma seems to be shutting down its own notification daemon in favor of anything else that's running, and I'm not sure if there's a way to prevent it from doing that

I don’t use Thunderbird, but does it support using FreeDesktop notifications e.g. that would work with Mako? Some applications will fall back to their own windows if there’s no notification daemon running.