[Feature Request] "busy" mode to mute notification sounds

[tremby]

Is your feature request related to a problem?

When I walk away from the computer it still makes notification sounds. If I had been doing something loud during the day, the volume is still loud at night, and the notification sounds still play loudly.

Describe the solution you'd like

I want the ability to tell Telegram-desktop that I want notifications muted. Some chat apps call this "busy".

Crucially I want to be able to enable and disable this from a script, so I can make locking my computer automatically mute Telegram-desktop, and unlocking it restore the previous state.

Describe alternatives you've considered

• Could remember to quit the app, but I am forgetful, and like to leave it running anyway.
• Could remember to turn down the volume or switch off the speakers, but sometimes I want music to continue playing while the system is locked.
• Could tell Pulseaudio to mute the Telegram client, but Pulse only knows about Telegram at the very moments it is playing sound, so I can't mute it while it is not playing sound.

Other context

Though not my use case, this should also stop visible notifications, and so would also be useful for use cases like when making a presentation or streaming.

[ilya-fedin]

Telegram supports KDE's extension to the fdo notifications standard called inhibitions. Saying simpler, it reads Inhibited property at org.freedesktop.Notifications D-Bus service. Ask your DE or notification daemon to support it.

[tremby]

If I understand you correctly, Telegram reads a non-standard setting in the freedesktop.org DBus tree to decide whether or not to send notifications. As far as I can tell, zero of the standalone notification daemons listed on the Arch wiki support setting it when you toggle their "do not disturb" options, such as xfce4-notifyd's one.

Meanwhile, Telegram doesn't actually send its notifications via the org.freedesktop.Notifications service; it seems to have its own implementation of notifications.

Do I have this right?

Do you know of a way to change this setting from the command line? Maybe it's possible with dbus-send? I don't know much about DBus and I'm not able to figure this out from its documentation.

Or else, might it be possible to opt out of Telegram's own notification implementation and have it use the system one instead?

[ilya-fedin]

As far as I can tell, zero of the standalone notification daemons listed on the Arch wiki support setting it when you toggle their "do not disturb" options, such as xfce4-notifyd's one.

Well, that's why I'm saying "Ask your DE or notification daemon to support it". Telegram can't do much if the system doesn't expose this information.

Do you know of a way to change this setting from the command line?

This should be supported by your notification service.

Or else, might it be possible to opt out of Telegram's own notification implementation and have it use the system one instead?

Do you have ever looked at notification settings in Telegram? 😕
Sound will still be played by tdesktop itself though, since the sound capability is not widely adopted and notification daemons that implement it, doing this in non-predictable ways (the spec is really bad about this).

[tremby]

Do you know of a way to change this setting from the command line?

This should be supported by your notification service.

Well it isn't supported by anything but KDE as far as I can tell.

Or else, might it be possible to opt out of Telegram's own notification implementation and have it use the system one instead?

Do you have ever looked at notification settings in Telegram? confused

I had not looked thoroughly enough. Now I have and I see the option to use native notifications. Good. Thanks.

Sound still will be played by tdesktop itself though, since the sound capability is not widely adopted and notifications daemon that implement it, doing this in a non-predictable way (the spec is really bad about this).

This seems like a bug. Notification sounds should be disabled as soon as the user opts to use native notifications, since the user's notification daemon might make sounds of its own.

Since you do something special for KDE, could you also read XFCE's "do not disturb" flag? You can get it via xfconf-query -c xfce4-notifyd -p /do-not-disturb. If it's true, Telegram shouldn't play the sound or show the notification.

[ilya-fedin]

Well it isn't supported by anything but KDE as far as I can tell.

Well, I don't see other proposations for the spec about this.

Since you do something special for KDE, could you also read XFCE's "do not disturb" flag?

The only reason it's supported is it's an addition to the fdo spec and gets the state by the same protocol without involving any DE-specific settings storages and ugly terminal commands.

[ilya-fedin]

Notification sounds should be disabled as soon as the user opts to use native notifications, since the user's notification daemon might make sounds of its own.

tdesktop sets suppress-sound hint.

[tremby]

The only reason it's supported is it's an addition to the fdo spec and gets the state by the same protocol without involving any DE-specific settings storages and ugly terminal commands.

OK. I've asked the XFCE developers if they'll support that extension, and also the developers of another standalone notification daemon (Github shows the reference above).

Notification sounds should be disabled as soon as the user opts to use native notifications, since the user's notification daemon might make sounds of its own.

tdesktop sets suppress-sound hint.

OK, so that would mitigate two sounds playing at once in the case where the user has set up standard system notifications to make a sound, as long as the notification daemon supports that flag. But I was just trying to conjure up another example of a problem caused by the sound.

The suppress-sound flag doesn't help me in this case -- the whole point of this is that I want Telegram to stop giving notifications when I've locked the computer or am giving a presentation. I tell XFCE that I'm in "do not disturb" mode and so it logs notifications for later, but Telegram is still making noise.

The notification sound is part of the notification, so "use native notifications" should switch off Telegram's (non-native) notification sound. Don't you think so?

[ilya-fedin]

The notification sound is part of the notification, so "use native notifications" should switch off Telegram's (non-native) notification sound. Don't you think so?

Quoting myself just in case you skipped that part of the message:

Sound will still be played by tdesktop itself though, since the sound capability is not widely adopted and notification daemons that implement it, doing this in non-predictable ways (the spec is really bad about this).

[ilya-fedin]

I've asked the XFCE developers if they'll support that extension

Here's the draft: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/24/diffs?diff_id=61049#da076cf2b48b541efea144496447f56f7a2aeb38_1096_1151

tdesktop just checks for inhibitions capability and the property itself (in case some sandbox mechanism blocks access to it, like old versions of snapd)

[tremby]

Quoting myself just in case you skipped that part of the message:

No, I did read that part.

Why do you care that the notification daemons don't support the standard sound enough to code in a workaround, while not caring that daemons don't support the non-standard inhibitions?

Here's the draft: https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/24/diffs?diff_id=61049#da076cf2b48b541efea144496447f56f7a2aeb38_1096_1151

You've pointed right to a very good argument against the existence of that flag.

tdesktop just checks for inhibitions capability and the property itself (in case some sandbox mechanism blocks access to it, like old versions of snapd)

That's another good reason not to rely on that flag. I misunderstood.

The solution for non-KDE users is this: if "native notifications" are enabled, disable the non-native notification sound and send the custom sound hint in the native notification request. If the daemon doesn't support that, or does something non-predictable, then isn't that just the user's problem? Tell the users to ask their notification daemon developers to fix their implementation of the standard, just like with the non-standard flag you're telling me to get the daemons to support.

[ilya-fedin]

Why do you care that the notification daemons don't support the standard sound enough to code in a workaround, while not caring that daemons don't support the non-standard inhibitions?

In the first case the default UX will be bad and @john-preston won't allow such change, in the latter case it's a bad UX only for those who want to disable the sound automatically

[tremby]

In the first case the default UX will be bad

I don't understand -- "native notifications" is off by default.

[tremby]

in the latter case it's a bad UX only for those who want to disable the sound automatically

Who wouldn't want sound suppressed when they've intentionally set their machine to "do not disturb"...?

[ilya-fedin]

I don't understand -- "native notifications" is off by default.

A lot of users enable it explicitly. Also, it's not really off by default, the default is decided based on daemon capabilities:

tdesktop/Telegram/SourceFiles/platform/linux/notifications_manager_linux.cpp

Lines 310 to 330 in 3343880

	bool IsQualifiedDaemon() {
	// A list of capabilities that offer feature parity
	// with custom notifications
	static const auto NeededCapabilities = {
	// To show message content
	qsl("body"),
	// To make the sender name bold
	qsl("body-markup"),
	// To have buttons on notifications
	qsl("actions"),
	// To have quick reply
	qsl("inline-reply"),
	// To not to play sound with Don't Disturb activated
	// (no, using sound capability is not a way)
	qsl("inhibitions"),
	};
	return ranges::all_of(NeededCapabilities, [&](const auto &capability) {
	return CurrentCapabilities.contains(capability);
	}) && InhibitionSupported;
	}

[tremby]

So you're saying the UX is "only bad for a lot of users".

Add another config flag then, for whether to attempt to use native notification sound rather than Telegram's own sound? That way I and anyone else in my position could avoid the bad UX.

[ilya-fedin]

Who wouldn't want sound suppressed when they've intentionally set their machine to "do not disturb"...?

This is not the right question, the right question is "How much users will complain after disabling sound for most of native notifications users?". That is, from my tests the sound was played only by GNOME's notification daemon. And it played only the sound from system sound theme, none of the daemons want to play tdesktop's mp3 notification sound.

[ilya-fedin]

Add another config flag then

tdesktop follows 'less options is better' paradigm, sorry

[tremby]

And apparently also the "a bad UX is fine even if it affects a lot of users" and "the options we have shouldn't act like the user would expect them to" paradigms.

I'll just disable all sound.

[ilya-fedin]

And apparently also the "a bad UX is fine even if it affects a lot of users"

Sorry, there's no good solution given the restrictions tdesktop's core developer offer and the bad standartization state.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.