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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg