DBus signal to disable reminders/notifications

[Simon McVittie]

On Tue, 18 Dec 2018 at 22:21:24 +0100, David Faure wrote:
> Is there some spec that would allow to implement a desktop-wide signal in 
> order to disable things like calendar reminders, chat notifications, new email 
> notifications etc. during a presentation?

Would it be better for your chosen implementation of o.fd.Notifications to
(be configurable to) suppress some or all popups during presentation mode?
Then instead of having to send a broadcast to all interested apps, the
presentation software would just have to tell the single implementation of
o.fd.Notifications "I am doing a presentation, don't show popups", and
then later "I've finished doing a presentation and I no longer have any
objection to popups", a bit like the various "inhibit suspend" APIs.

The apps that create notifications would still send their messages to
Notifications, and they'd still build up in (for example) the GNOME
notifications list to be looked at later, they just wouldn't have any
immediate visible or audible effect.

The popups could even all appear together on exit from presentation mode,
if that's the UX that the o.fd.Notifications implementor wants.

https://extensions.gnome.org/extension/964/do-not-disturb-button/ is a
non-automated implementation of this (it goes into do-not-disturb mode
when you click on it, rather than automatically).

Straw-man API (1):

    org.freedesktop.Notifications.GetCapabilities()
         Returns "presentation-mode" if this feature is supported

    method org.freedesktop.Notifications.EnterPresentationMode() -> void:
        Increment a reference count for presentation mode.
        PresentationMode is true if the reference count is > 0.
        When the caller (unique name) of EnterPresentationMode
        disappears from the bus, all of its references are automatically
        discarded.

    method org.freedesktop.Notifications.LeavePresentationMode() -> void:
        Undo one prior call to EnterPresentationMode.
        Return an error if the caller (unique name) does not own any
        references.

    property org.freedesktop.Notifications.PresentationMode:
        read, bool, emits PropertiesChanged

        Any other applications that want to detect presentation mode watch
        this property.

Straw-man API (2):

    Applications that want to enter presentation mode request the name
    org.freedesktop.Notifications.Presentation, with flags that must not
    include DO_NOT_QUEUE (so that multiple applications can queue for it
    at the same time if they want to). They must not treat the IN_QUEUE
    reply as an error.

    Notifications implementations, and any other applications
    that want to detect presentation mode, watch the name-owner of
    org.freedesktop.Notifications.Presentation using NameOwnerChanged
    and GetNameOwner() (preferably using GLib's g_bus_watch_name(),
    which gets all the details right for you, or another library's
    equivalent). If there is a primary owner (meaning there is at
    least one owner in the queue), then we are in presentation mode.

> Calligra Stage, LibreOffice Impress and other presentation software could emit 
> a dbus signal when starting/stopping a presentation, and calendar/email 
> software would listen to that and disable/enable reminders/notifications.

Changing every application that *sends* notifications seems like a
boil-the-ocean task, compared with changing every piece of desktop
infrastructure that *displays popups for* notifications (GNOME Shell and
its equivalents in other desktops, plus notification-daemon and a couple
of other non-desktop-integrated implementations).

Some (mostly older) applications implement reminder/notification popups
by creating their own undecorated X11 windows with absolute positioning
instead of by doing D-Bus communication with o.fd.Notifications, but we
can't assume those applications will respect a new D-Bus API either,
and they can always query the PresentationMode property or look for
the org.freedesktop.Notifications.Presentation bus name if they want to.

> Calligra Stage, LibreOffice Impress and other presentation software could emit 
> a dbus signal when starting/stopping a presentation

D-Bus APIs that do not have state-recovery are problematic: any app or
service that (re)starts after your proposed signal was emitted would
not know you were in presentation mode. It's nearly always better
to design a way to query what is going on, and then add
change-notification for the result of that query having changed.

If you don't want the API to be "call a method on Notifications" then
I would recommend using a bus name, as in straw man API (2) above.

    smcv