bug: taffybar should enable status-notifier-watcher by default (fails on first start without it)

[cumber]

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

I'm not 100% sure if this is really a bug or a feature request here, but:

I think we can improve the UX by having services.status-notifier-watcher .enable default to true if services.taffybar.enable is true.

I had been using taffybar and nm-applet together for a long time, using a manual startup script. I've been gradually migrating things out of my manual script into services configured by Home Manager, and noticed both taffybar and nm-applet had existing modules, so I tried switching those on. The problem I had was that the network widget would never appear in the tray, unless I killed my session and logged in a second time after each boot.

I noticed that the journal always showed taffybar fail with this error:

 taffybar[1412]: taffybar: user error (Pattern match failure in do expression at src/System/Taffybar/Widget/SNITray.hs:79:3-11)

Systemd would then immediately restart taffybar and there would be no error the second time. This error would only happen on the first session after boot. I think that nm-applet was being started by systemd after the first invocation of taffybar but before the restart, and it never hooked up properly with taffybar's tray watcher.

Anyway, I was getting all ready to file a bug on taffybar, but looking for related bugs there led me to find that it is recommended to start status-notifier-watcher before taffybar, rather than rely on taffybar's ability to start a watcher by itself. I then noticed that Home Manager also has services.status-notifier-watcher (configured so that systemd will start it before taffybar). I tried enabling that service too, and the first-startup error in taffybar stopped happening (and nm-applet appears in the tree on first session after boot).

So, is it possible to make services.taffybar.enable = true imply status-notifier-watcher.enable = true by default? I would submit a pull request but I'm pretty green with writing nixos modules, not sure how to do the conditional default depending on another module (I would like to see how that's done, actually).

Maintainer CC

@pltanton @rycee

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.15.49, NixOS, 22.11 (Raccoon), 22.11.20220626.f2537a5`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.9.1`
 - channels(root): `"nixos-21.03pre249162.1dc37370c48"`
 - nixpkgs: `/nix/store/1qz0d0cx49ic26jynvb6fqmzl138rj0s-source`

[cumber]

Actually I see from https://github.com/nix-community/home-manager/pull/314 that it was decided that status-notifier-watcher shouldn't be a dependency of taffybar, even by default. Maybe we should add an option to taffybar so people can discover it from there? Or even just a note in the description of taffybar that you might want to enable status-notifier-watcher as well?

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.