dunst VS Waybar

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.

If I understand https://github.com/Alexays/Waybar/wiki/Configuration correctly, what is to be displayed is defined in a JSON file that can be located in one of the directories mentioned.

GNU calls their extensions "equivalent to" things I'd have suggested trying ($_I or $-l), but I'm not sure if the equivalents are themselves GNU extensions, too. Regardless, reading this Waybar Github issue about %OI, I get the impression there was a regression at some point, in any case on March 27th 2022 someone says it "used to work fine until recently".

hope it helps. source btw: https://github.com/Alexays/Waybar/issues/2177

{ config, pkgs, ... }: { wayland.windowManager.sway = let patchedWaybar = pkgs.waybar.overrideAttrs(prev: final: { patches = [ (pkgs.fetchpatch { url = "https://github.com/Alexays/Waybar/pull/2134.diff"; sha256 = "1hzdv3b8zzps50pdcb8pj9cxwaix4q2d4gsqb9dl9vflgl429hq3"; }) ]; }); in { enable = true; config.bars = [{ statusCommand = "${patchedWaybar}/bin/waybar"; }]; };

See this issue. CSS and only new properties in config are reloaded when SIGUSR2 is triggered.

I think this has just been added to waybar (wlr/workspaces) to work in a similar manner to how it is in sway/workspaces. No need for fake empty terminals. Something was merged for wwlr/workspaces in the waybar github. See - https://github.com/Alexays/Waybar/pull/2089.

Ah, well in looking at their git, it appears some do have fallback font issues. See here - https://github.com/Alexays/Waybar/issues/215