nixpkgs icon indicating copy to clipboard operation
nixpkgs copied to clipboard

Dino Messenger with no default config (sound off) compared to versions elsewhere.

Open maikelthedev opened this issue 1 month ago • 10 comments

I'm using XMPP and found Dino client to be the most adequate to my tastes, but the notification saound cannot be disabled. I talked to one of the developers in Mastodon and discovered Nixos has exceptionally sounds on enabled for everybody in only Nixos whereas every other Linux has it by default disabled.

Can this be fixed (the line below) to have Dino deploy the same that it does everywhere else, with no sounds enabled by default. There's nowhere in the settings to disable that otherwise, there's a file I could delete but it'll come again whenever I "nixos-rebuild switch".

https://github.com/NixOS/nixpkgs/blob/998d10d2d404fac4ebcf76f472d674a2ff1e697f/pkgs/applications/networking/instant-messengers/dino/default.nix#L93

Alternatively for it to be a Nixos option like this

dino.enable = true
dino.bell_sound.enable = off

maikelthedev avatar Dec 10 '25 14:12 maikelthedev

@alyssais

maikelthedev avatar Dec 10 '25 15:12 maikelthedev

You can override it locally for now. Replace pkgs.dino with the below:

(pkgs.dino.overrideAttrs (o: {
  mesonFlags = o.mesonFlags ++ [ (lib.mesonEnable "plugin-notification-sound" false) ];
}))

Also, kind of wild that upstream does not provide a way to disable sounds without recompiling the entire application - to me that's a basic feature of a chat app 🤷

eclairevoyant avatar Dec 12 '25 09:12 eclairevoyant

@SuperSandro2000

alyssais avatar Dec 12 '25 09:12 alyssais

Also, kind of wild that upstream does not provide a way to disable sounds without recompiling the entire application - to me that's a basic feature of a chat app 🤷

I would agree if sounds being disabled weren't their default for any other version except the one in nixpkgs that they have no control of.

And btw thank you very much for providing a temporary solution I can just paste in configuration.nix

maikelthedev avatar Dec 12 '25 09:12 maikelthedev

For context: I just enabled all optional features, lol.

Alternatively for it to be a Nixos option like this

dino.enable = true dino.bell_sound.enable = off

There are no options for dino, you likely refer to home-manager or so.

SuperSandro2000 avatar Dec 13 '25 16:12 SuperSandro2000

#470490

SuperSandro2000 avatar Dec 13 '25 17:12 SuperSandro2000

Upstream maintainer here.

This notification-sound plugin was not meant to be an "optional" feature. This is a hack for systems that don't have a notification daemon or run a notification daemon without sound support. It's also a demo on how to do platform-specific plugins for notification systems (e.g. to cater to Windows or macOS notification systems).

I don't use that option and on a regular GNOME or KDE, I will still get notification sounds (if I don't turn them off, which is configured in the system settings, not in Dino).

Image

Just because code exists doesn't mean it's meant to be delivered to everyone. For all of these options that are disabled by default and that NixOS override the default to enable them, there is good reason why they have been disabled:

  • plugin-notification-sound: Because on many systems it will cause double notification sound (the one from the notification daemon and the one from the plugin). There's unfortunately no universal way to discover if the notification daemon will do a sound, but also it seems much better to have that done by the notification daemon in general rather than copying the logic into every app.
  • plugin-rtp-h264 due to licensing issues and poor performance of software codec implementations
  • plugin-rtp-vaapi due to instability and issues on some GPUs and drivers (reported issues include system/GPU crashes and significant glitches)
  • plugin-rtp-vp9 due to issues with higher packet loss on some systems and higher latency only to gain better compression for high resolution webcams (that are very rare on supported systems)
  • plugin-rtp-msdk as it may trigger the same issues as plugin-rtp-vaapi.

The issues related to stability of hardware encoding/decoding probably have improved by now. Our plan is to start to selective enable VAAPI based on a GPU allow- or denylist, which is not uncommon in other software as well.

Anyway, now you know: Things being disabled by default means that us, the upstream developers, consider this the best option. You, the NixOS package maintainers, are always open to override the default if you consider it better for your users. We will then direct your users here if they have problems due to such decision, which is exactly why this issue was opened in first place (user assuming it's a bug in Dino that they can't turn notification sounds off).

If you really feel you want to provide this notification plugin, there's also the option to package it independently. Alpine does it like that, meaning that users that want to have it, will install the package dino-notificationsound in addition to the dino package.

mar-v-in avatar Dec 13 '25 17:12 mar-v-in

Upstream maintainer here.

This notification-sound plugin was not meant to be an "optional" feature. This is a hack for systems that don't have a notification daemon or run a notification daemon without sound support. It's also a demo on how to do platform-specific plugins for notification systems (e.g. to cater to Windows or macOS notification systems).

I don't use that option and on a regular GNOME or KDE, I will still get notification sounds (if I don't turn them off, which is configured in the system settings, not in Dino).

Image

Just because code exists doesn't mean it's meant to be delivered to everyone. For all of these options that are disabled by default and that NixOS override the default to enable them, there is good reason why they have been disabled:

  • plugin-notification-sound: Because on many systems it will cause double notification sound (the one from the notification daemon and the one from the plugin). There's unfortunately no universal way to discover if the notification daemon will do a sound, but also it seems much better to have that done by the notification daemon in general rather than copying the logic into every app.
  • plugin-rtp-h264 due to licensing issues and poor performance of software codec implementations
  • plugin-rtp-vaapi due to instability and issues on some GPUs and drivers (reported issues include system/GPU crashes and significant glitches)
  • plugin-rtp-vp9 due to issues with higher packet loss on some systems and higher latency only to gain better compression for high resolution webcams (that are very rare on supported systems)
  • plugin-rtp-msdk as it may trigger the same issues as plugin-rtp-vaapi.

The issues related to stability of hardware encoding/decoding probably have improved by now. Our plan is to start to selective enable VAAPI based on a GPU allow- or denylist, which is not uncommon in other software as well.

Anyway, now you know: Things being disabled by default means that us, the upstream developers, consider this the best option. You, the NixOS package maintainers, are always open to override the default if you consider it better for your users. We will then direct your users here if they have problems due to such decision, which is exactly why this issue was opened in first place (user assuming it's a bug in Dino that they can't turn notification sounds off).

If you really feel you want to provide this notification plugin, there's also the option to package it independently. Alpine does it like that, meaning that users that want to have it, will install the package dino-notificationsound in addition to the dino package.

The fact the package was added without understanding what any of these packages do puts into question why was the choice made of altering defaults at all and pushing them to NixOS 25.11

Can we all agree there needs to be better quality control on the NixOS side about this or at the very least not alter defaults without a reasonable cause ?

maikelthedev avatar Dec 13 '25 18:12 maikelthedev

The fact the package was added without understanding what any of these packages do puts into question why was the choice made of altering defaults at all and pushing them to NixOS 25.11

Firstly, let me explain you some details of the NixOS release process: Anything that is currently in master and will land before the branch of to 26.05 in master, will be in 26.05. There is no separate process to pick single packages or modules or changes to a release version. Sometimes and rarely some things are reverted right before a release or in a release because they are not stable enough, yet, but that is usually not for single packages and only is regarding core NixOS functionality.

So the change done here 8 months ago https://github.com/NixOS/nixpkgs/commit/acac22aafcfba3a891f7a5d24e50bd207f498b22 will automatically land in the next release aka 25.11.

Originally the video codec plugins where added here https://github.com/NixOS/nixpkgs/pull/215211 2,5 years ago.

The defaults of meson options are usually really not that deep. Sometimes things are disabled by default because extra dependencies would be required or auto-detection does not properly work. It is not uncommon for us to enable extra features.

Can we all agree there needs to be better quality control on the NixOS side about this or at the very least not alter defaults without a reasonable cause ?

NixOS is an open source project run by the community. If you encounter quality bugs, the best way to increase quality is to figure the problem out and open a PR to fix it. You can also review pull requests or just be active in the matrix channel and help people with problems.

SuperSandro2000 avatar Dec 13 '25 19:12 SuperSandro2000

This notification-sound plugin was not meant to be an "optional" feature. This is a hack for systems that don't have a notification daemon or run a notification daemon without sound support. It's also a demo on how to do platform-specific plugins for notification systems (e.g. to cater to Windows or macOS notification systems).

I don't use that option and on a regular GNOME or KDE, I will still get notification sounds (if I don't turn them off, which is configured in the system settings, not in Dino).

Thanks for clarification and that is good to know! I would wish that this would be reflected here https://github.com/dino/dino/blob/master/meson_options.txt#L10 or here https://github.com/dino/dino/wiki/Build#:~:text=-dplugin-notification-sound%3Denabled . Then we would probably have caught that.

Just because code exists doesn't mean it's meant to be delivered to everyone. For all of these options that are disabled by default and that NixOS override the default to enable them, there is good reason why they have been disabled:

Then they should probably be marked with experimental or so. Then we would probably not have them enabled per default. We are so used to people disabling features per default to not confuse people that they actually need those dependencies or to reduce default depencies or something, usually an option being auto or disabled is not a pretty strong indication if it is ready to enable for everyone or not.

Our plan is to start to selective enable VAAPI based on a GPU allow- or denylist, which is not uncommon in other software as well.

That is probably not a good idea. Chrome/Firefox do the same and the standard advice on eg ArchWiki is to ignore those to get things working.

If you really feel you want to provide this notification plugin, there's also the option to package it independently. Alpine does it like that, meaning that users that want to have it, will install the package dino-notificationsound in addition to the dino package.

That will probably not work out of the box as dino probably only searches for plugins in its install path and it is not possible to install packages there.

Edit: see https://github.com/dino/dino/blob/197adcd2953ac0f56cd18e686fd2ba1f20b5de33/meson_options.txt#L1

SuperSandro2000 avatar Dec 13 '25 19:12 SuperSandro2000