Are XFCE Plugins like the pulse audio volume control handled as standalone programs instead of as part of xfce?


I am new to NixOS, coming from Fedora. I installed NixOS with the XFCE DE. At first I was confused, that there was no bluetooth manager, so I enabled blueman in the configuration (which I now have set up as a flake). Now I realized that the volume control buttons of my thinkpad do nothing and xfce does not have any audio controls. As far as I can tell, those would be provided with xfce.xfce4-pulseaudio-plugin (that would then communicate with pipewire which is my actual soundserver). But other than xfce itself and blueman, xfce.xfce4-pulseaudio-plugin is handled like a program/package in the configuration file.

I am trying to understand how these distinctions are made. I guess only the absolutely necessary parts of the DE are considered part of the DE and everything else is a package, but blueman is part of the core os and therefore a service? And if I removed xfce as DE, the xfce plugins would still be there and would have to be removed seperately?

Hello. You are right that there is a distinction between programs that can be installed by only adding a package in environment.systemPackages and programs that have a dedicated nixos option. It is often the case that when a program has a dedicated option, installing with environment.systemPackages instead does not work.

To understand the reason, one must be quite familiar with the internals of each package, and understand finely what it means to install this package. Adding to environment.systemPackages, in first approximation, only adds /nix/store/somehash-foo/bin to $PATH. So is it enough for git, sl or diffoscope for example, because for git to work correctly it is enough to have it on PATH. However this fails other packages for different reasons:

  • it fails for nginx, because systemd will not pick up its service file and therefore will not start nginx
  • it fails if you want to use fish as your login shell, because login shells must be registered in /etc/shells
  • it fails for, say, android-udev-rules, because udev rules will not be picked up
  • it fails for sudo because /nix/store cannot contain setuid executables

Most programs that have a dedicated nixos options need it to put some files in /etc (systemd service files in /etc/systemd, udev rules, etc) Installing those programs needs more integration with the OS than merely adding to PATH.

Sometimes there is no dedicated option but you still need to do more effort: a package with an executable plus a udev rule must be added to both environment.systemPackages and services.udev.packages to work properly.

To be a bit more precise:

  • nix-env adds $out/bin to PATH and $out/share to XDG_DATA_DIRS, which is enough to pick up application desktop files
  • environment.systemPackages adds $out/bin to PATH and $out/share to XDG_DATA_DIRS, but also registers polkit rules, maybe fonts and a few other things.
  • NixOS options (or home-manager options in some cases) are needed to cover the rest.

You can see in the service for blueman nixpkgs/blueman.nix at fda0d99c2cbbb5c89d8855d258cb0821bd9113ad · NixOS/nixpkgs · GitHub that blueman needs udev rules, a systemd service, and to be on PATH and XDG_DATA_DIRS so that DE execute the applet. On the contrary, I suspect that the xfce plugin you refer is happy with only being on PATH and having some xdg desktop files in XDG_DATA_DIRS, so environment.systemPackages is ok.

1 Like