GNOME Bugzilla – Bug 633297
Don't use a status icon in evolution-alarm-notify
Last modified: 2015-06-15 10:03:55 UTC
The calendar alarm feature seems to use a status icon to provide persistence for the notification of the alarm. This isn't needed when the notification server supports persistence of messages itself. Please see: http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
How do you tell the notification daemon that it may not close the status icon, but can the notification itself? Because for calendar alarm notifications we show a notification with an icon and alarm description, but let it disappear with the status icon kept, which, on click, shows list of alarms. If you removed actions on status icons, to which we do not have access in gnome-shell, if I got it right, then we really loose a functionality here. Please tell me I'm wrong here and how I can do this. Furthermore where is the documentation on this located (I'm really not going to investigate how all this works through sources for libnotify and daemon).
I think you want notification_notify_set_hint (notification, "resident", g_variant_new_boolean (TRUE));
OK, thanks, and the popup menu over the icon, please? I know you can add actions to the notification, but I understand it like an action in the bubble, not on the status icon itself. Also, pretty stupid question, how do I test any changes I may do? I suppose it's not enough to just compile evolution against newer gtk3 and/or libnotify, or is it? Because breaking my main development system with gtk3 so early is something I would rather postpone a bit.
I don't think you get to keep custom actions on the statusicon. As for testing, I think if you use gnome-shell in rawhide, and build use the tests that live in the libnotify git repository, you can get a pretty good feel for what kind of notifications the shell offers you.
[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. "nice-to-have" categorisation for GNOME3.0]
Any update on this?
*** This bug has been marked as a duplicate of bug 735747 ***