GNOME Bugzilla – Bug 788802
GNotification: Add support for "closed" signal, body-markup, sound
Last modified: 2017-11-17 11:38:19 UTC
There a number of capabilities in the Notifications spec, that are supported by the Gnome notification daemon but are inaccessible in GNotification. A short list: * body-markup: it's not possible to send notifications with basic Pango markup * closed signal: there's no way to connect to a notification being closed explicitly by the user (or query un-withdrawn notifications) * hints: although the notification daemon can supports the "sound" capability there's no way to set a hint to this effect If these haven't been purposefully removed or avoided, could they be added?
they have been more or less purposefully avoided, yes
(In reply to Matthias Clasen from comment #1) > they have been more or less purposefully avoided, yes We should probably briefly add the reasoning to the GNotification documentation and point people to more fully-featured alternatives if they do need the additional functionality. What’s the reasoning?
(In reply to Philip Withnall from comment #2) > What’s the reasoning? Matthias?
See also: bug #750926, about adding sound-name support.
Markup is a really slippery slope towards full html. Why can't express the content of your notification with a plain text sentence and actions ? The new notification system has been carefully designed to avoid the need for reacting to a notification being closed - the intention is that you send the notification and specify sufficient parameters to your actions that the system can reactivate your app with the proper content if the user activates an action. This is meant to free you from having to track the state of your notification in the running app and make the system robust against application crashes and restarts. A closed signal does not really fit into this model. For sound, I don't really see any reason to tie that into the notification system. If your app has a need to make noise, just play sound. libcanberra makes it very easy to do.
It's true markup is just a nicety and notifications should be simple, but it can make for clearer presentation. The only real irk is the tiny icon size with a lack of <img> tag. For example, showing a contact avatar with an incoming message is basically a no go with 16px. My use case for wanting a "closed" signal is pretty specific, and I can see why it's rarely useful, and probably hard to track between instances since I assume the GNotification object is gone. With regards to sound, the only issue I have with this is its support in the org.gnome.desktop.notifications schema. Playing sounds is not much of an issue, but respecting the user settings is more work since it has to be queried.
(In reply to andrew.g.r.holmes from comment #6) > It's true markup is just a nicety and notifications should be simple, but it > can make for clearer presentation. The only real irk is the tiny icon size > with a lack of <img> tag. For example, showing a contact avatar with an > incoming message is basically a no go with 16px. I agree with Matthias that we don’t want to support full markup. I haven’t followed the most recent changes to the notifications in gnome-shell, but I suspect that if they don’t meet your needs (wrt avatars, or anything else), you should speak to the gnome-shell designers and see what they suggest. If what they come up with ends up requiring new API in GLib (or whatever), then we can reconsider this. What I want to avoid is adding new API piecemeal in GLib without it being considered as part of a bigger plan for how notifications should work for all desktop apps. > My use case for wanting a "closed" signal is pretty specific, and I can see > why it's rarely useful, and probably hard to track between instances since I > assume the GNotification object is gone. Yup, the GNotification object is gone. I agree with Matthias here. > With regards to sound, the only issue I have with this is its support in the > org.gnome.desktop.notifications schema. Playing sounds is not much of an > issue, but respecting the user settings is more work since it has to be > queried. That’s the kind of thing which libcanberra should do for you (I haven’t checked whether it does, but it should).
⇒ WONTFIX.
*** Bug 751516 has been marked as a duplicate of this bug. ***