Hi,
while API (2) is certainly an interesting pattern, I would be in favor
of something along the lines of (1).
However, I think it shouldn't be tied to "presentations" but more of a
generic inhibition concept, as there could be other reasons not to show
notificaton popups, like time-based or location-based triggers, explicit
user "do not disturb" mode, etc.
I propose the following API based on (1):
method org.freedesktop.Notifications.GetCapabilities() -> void:
Returns "inhibitions" if this feature is supported
method org.freedesktop.Notifications.Inhibit(string desktop_entry,
string reason, dict hints) -> uint:
Increment a reference count for notification inhibitions.
When the caller (unique name) of Inhibit disappears from the bus,
all of its references are automatically discarded.
desktop_entry: This specifies the name of the desktop filename
representing the calling program. This should be the same as
the prefix used for the application's .desktop file.
An example would be "libreoffice-impress" from
"libreoffice-impress.desktop".
This can be used by the daemon to retrieve the correct icon for the
application, for logging purposes, etc.
reason: Human-readable, descriptive string of why notifications
are inhibited. Example: "Giving a presentation", "Privacy mode engaged"
hints: Optional hints that can be passed to the server from the
client program.
Can be empty.
Returns a cookie uniquely representing the inhibition request,
to be passed to UnInhibit when done.
method org.freedesktop.Notifications.UnInhibit(uint cookie):
Undo inhibition call of given cookie.
Return an error if the caller (unique name) does not own the cookie
it passes.
property org.freedesktop.Notifications.Inhibited:
read, bool, emits PropertiesChanged
True when any application is inhibiting notifications, false otherwise.
method org.freedesktop.Notificatons.ListInhibitors() -> list<string,
string, dict>
Lists all currently active notification inhibitions. It returns an
array of
structs, each consisting of desktop_entry, reason, hints like the
Inhibit call.
I would like to have the caller pass its desktop entry name for
identification as well as a reason for the inhibit that we could show in
the UI. While the desktop entry doesn't change for the lifetime of the
application, the reason potentially could when the app requests another
inhibition.
I don't really like making the client-side deal with cookies, though,
just calling Inhibit and calling the same amount of UnInhibit as in (1)
is much nicer.
Possible solutions:
1. Allow only one inhibition per application, if they request another one:
a) Throw an error
b) Overwrite the existing inhibition
2. Drop the reason
3. ???
Cheers
Kai Uwe Broulik
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
