Expose "Do not disturb" in a unique way

[cajus]

Operating System

Fedora 39

XDG Desktop Portal version

1.18

XDG Desktop Portal version (Other)

No response

Desktop Environment

GNOME

Desktop Environment (Other)

No response

Expected Behavior

Current desktop environments like KDE, GNOME and Xfce have a feature to enable a DND mode. Currently this seems to be meant for standard desktop notifications only, but that kind of flag also could be useful for other apps (i.e. VoIP clients, that need to send ring tones).

I would expect that a DND flag is a portal queryable/monitorable flag. Maybe in the way KDE already does that.

Current Behavior

As of now there is no unique way of advertising that the desktop environment is in DND mode:

KDE

For KDE, DBus is used in the org.freedesktop.Notifications interface, which adds an Inhibit flag there.

GNOME

Here, gsettings is used (org.gnome.desktop.notifications show-banners), which cannot be monitored properly from inside a flatpak.

Xfce

For Xfce, DBus is used org.xfce.Xfconf /org/xfce/Xfconf org.xfce.Xfconf.xfce4-notifyd /do-not-disturb.

There may be more - thats what I've found so far.

Steps to Reproduce

1. Toggle DND in your DE
2. Check if you can get hold of that information from inside a flatpak

Anything else we should know?

No response

[GeorgesStavracas]

I'll move this into a GitHub discussion since we GitHub issues strictly for bug reports nowadays

[cajus]

Thanks! Sorry for putting it in the wrong place...

[Mikenux]

Hello Cajus,

In https://github.com/flatpak/xdg-desktop-portal/pull/1304/files, there are sound, vibration and led-color properties which all seem playable by the system (if implemented). So, it is not necessary for apps to be aware of DND mode - it is just a matter of sending the appropriate signals. Read this PR a bit and say if anything is missing and/or wrong from your point of view.

[Mikenux]

This may be necessary in the case of an app playing radio or stream.

[cajus]

Thanks @Mikenux - will take a look at it. It sounds a bit like it could help for call handling (just bringing up a window at the desired position isn't easy in wayland times). No idea yet, if it helps with suppressing ring tones, etc. as the complete audio handling is routed via pipewire. Just a flag that says "do not disturb" would be completely sufficient.

But as said - I need to look at the PR more in depth.

[Mikenux]

I am not at all in favor of applications being aware of DND mode. In my opinion, DND is a setting that must be respected by applications, and giving them the possibility of being aware of it also gives them the possibility of disturbing. Perhaps it depends on how this will be implemented (something we don't know), but it's best to be cautious by default.

For applications playing sound on the application side (radio, stream), perhaps:

• Reserve this feature for alarm notifications (which in my opinion require other hints such as a precise time).
• Since we have a specific content type, users can grant an exception for alarms to sound in DND mode in system settings.
• Let them play the radio or stream only if we can mute the sound for them in DND and/or silent mode if the user does not allow sound. This avoids knowing that the user does not want an alarm to sound. The system can play a vibration or LED pattern predefined by the system, depending on user settings.

[deltragon]

Hello!
I am a co-maintainer of SafeEyes, an application to help prevent eye strain by regularly making the user take breaks.
Being able to detect whether DND mode is on would help us avoid triggering breaks at inconvenient times, eg. when sharing the screen. See this bug report: slgobinath/SafeEyes#644.

I do not think it makes sense to not expose DND mode to applications in case they might wilfully disturb - not exposing it is worse, as many more apps will then unknowingly disturb.

[Mikenux]

I already said what the problem is two times and will not repeat it again.

I’m asking for reasons to have DND awareness elative to features of an app, not arguments that say an app can disturb other ways or due to missing things in desktop environments (for that ask your DE devs).

For deciding where to ring and to handle a secondary call, please give more explanations on how it is handled. I don’t see what is the link with do not disturb.

[cajus]

The problem I have is that this whole DND issue is limited to notifications only, and no one can use this information in any other way. I'm just trying to explain why I think this is too short-sighted.

Mechanisms that go beyond a simple DND of notifications also exist on other platforms (in the Apple world this is called “focus”, Android also exports this flag), and allows e.g. chat applications to change something in the presence or to tell the chat partner that there will be no answer right now. Both platforms allow me to see the current state of DND.

In my case, the application can actually “disturb” the user in other ways without the desktop environment being able to intervene. Sure, the "ring example" is a bit special, because the application knows how to use the hardware bell of USB phone devices. But I guess we can agree on "a Linux DE will not have a concept for this anytime soon". So I've the choice to not use the hardware bell, or potentially disturb a meeting of the user.

So - in my opinion, the mere fact that an application can disturb the user in other ways, but wants to behave nicely by being interested in the user's DND information, is reason enough to be able to obtain this information. I've currently no chance to do so.

This is a convenience feature - whether as “permission” or whatever: I think this information should be elevated.

[Mikenux]

Currently, DND seems only linked to notifications. If linux DEs don’t have a concept of what you want, then this concept is needed before implementing anything. If DND awareness is exposed without a common concept on what it is, then you will end up by assuming things you can’t assume.

For the two others cases you mentioned:

• Ring example. This can be handled by the system. When the user enables a mode to not distract them, they can choose to route audio to headset.
• Chat app example. This case justify DND awareness (but that’s for another than the app to distract the user).

So, ok, this can be proposed, but that will be limited to notifications and the message to the app will be ”you are allowed to disturb the user”, granted the user allowed this. For other ways to distract, that’s another subject.

[cajus]

* Ring example. This can be handled by the system. When the user enables a mode to not distract them, they can choose to route audio to headset.

A headset device is an USB HID device, where the various states are controlled by HID commands and they can send report events (i.e. on off hook). Ringing is a command and has nothing in common with ordinary audio handling. So I can't use this here and have to rely on an exported DND flag. Many headsets even have a DND indicator LED, which is also controlled by HID commands.

[Mikenux]

Ok. Could you report this case on #1142? (this is to provide information, since this is where we talked about headset management)

Note that DND awareness for that case is only if your app is not fully sandboxed.

[cajus]

I would work on a pull request for signaling the DND flag, but I don't feel like that's time well spent at the moment. @flatpak/xdg-desktop-portal are there any additional opinions here?

[Mikenux]

It seems reasonable to have DND awareness without permission, provided that an app doesn't know if it's in the list of apps allowed to disturb. In that case, maybe it's something for the settings portal?

@jadahl @swick @jsparber ?