guides VS dunst

i agree with this piece, as someone who likes man pages to the extent of having ported significant amounts of the s6-ecosystem docs to mdoc(7), and as someone who has also written a number of guides.

And the -bin kernel can be used to easily get many of the settings you'll need when you build your own kernel.

Gah, didn't even consider that the OP might have meant the cover image! Probably at least partly because i know that EPUBs don't necessarily need a cover image - i learnt this as a result of learning how to create a minimal EPUB. (And i actually have many EPUBs without a cover image.)

The point is to be able to customise where you want/need to, and to not have to when you don't. The -bin packages for FireFox, LibreOffice and Zig meet my needs, so i use them. i used the -bin package for the kernel to help me create a minimal kernel for my hardware, because messing around with kernel configuration is not my idea of a good time. But more generally, compiling allows me to specify things like: "i want packages compiled with USB and PCRE support where available, but i don't want them compiled with GNOME support."

Even though D-Bus is probably most often encountered by people in the context of GUI sessions, it's not specific to that; it can be (and is) used outside of such contexts. The widespread misunderstandings i've encountered about D-Bus over the years led me to write a short guide, "D-Bus: the essentials".

(Some related background you might find helpful: a guide i wrote about D-Bus and X sessions).

But more generally, you might find it helpful to refer to this guide i wrote on creating a minimal Gentoo-patched kernel via gentoo-kernel-bin (which can then be regularly updated just like any other Gentoo package).

Take advantage of savedconfig where appropriate, e.g. for kernel builds. In particular, this can be used to easily create a minimal kernel for your hardware.

(Further to this, you might be interested in my guide to creating a minimal kernel for your hardware.)

[a] i've actually written a quickstart guide to writing man pages with mdoc(7), to try to encourage others to use the semantics-oriented mdoc(7) macros for man pages, rather than the presentation-oriented man(7) macros.

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.