Message popups do not pay attention to notification daemon capabilities

Bug #332767 reported by Dylan McCall on 2009-02-22
This bug affects 33 people
Affects Status Importance Assigned to Milestone
Mail Notification
mail-notification (Ubuntu)

Bug Description

This issue is easily exposed using the new notification-osd from Ubuntu Jaunty. The notification daemon provides information regarding, for example, whether it will accept Actions for notifications. Even though it is told not to, mail-notification passes actions. In Jaunty, this triggers an ugly dialog with buttons to appear.

Mini-specification: <>

Dylan McCall (dylanmccall) wrote :

Here is my quick patch for this. Note that it needs testing and probably won't compile; I could not find this infamous gob 2.0.16 thus could not build the software. Oh, and I have never worked with gob code to begin with :/
Still, it may miraculously work.

Here is a patch based on Dylan's one but which apply directly on the .c and .h files (and other minor modifications), bypassing the gob files. Certainly not a clean way to do it but it works and you can use it while waiting for gob 2.0.16 release.

Miguelángel León (migueleonm) wrote :

It happens to me with emesene notifications... is really annoying

description: updated
Matthew Paul Thomas (mpt) wrote :

Thanks for reporting this. Just commenting out the actions would leave Mail Notification with almost a tab full of settings that don't do anything. In the mini-spec I've specified how the options should be invisible when Notify OSD is being used.

Dylan McCall (dylanmccall) wrote :

To be nice, I should mention here that it is possible to disable the actions in gconf-editor as a horrible workaround :)
Look in /apps/mail-notification/popups/actions. (Just delete everything in that list).

Pedro Villavicencio (pedro) wrote :

Got the same issue here, confirming, thanks for the report.

Changed in mail-notification (Ubuntu):
importance: Undecided → Low
status: New → Triaged
svasie (svasie) wrote :

I can confirm Dylan McCall workaround. Deleting all entries in /apps/mail-notification/popups/actions (gconf) makes notifications work as expected.

Jacob Peddicord (jpeddicord) wrote :

I'm making an attempt at fixing this and the other issues mentioned on I haven't been able to build Gob2 with the necessary patches at all, so this could be quite painful :)

Jacob Peddicord (jpeddicord) wrote :

That wasn't as bad as I thought it would be. Subscribing u-u-s for Karmic; a testing package will be available in my PPA shortly:

Jacob Peddicord (jpeddicord) wrote :

Scratch that last debdiff; libeel2 seems to have been removed from Karmic. However, I was able to build it without a dependency on libeel2. In fact, I can't find anything in the original README that states that libeel is required. This patch should build; it is the same as my last with the exception of the dependency removal. Once again, a test package is building in my PPA.

Maia Everett (linneris) wrote :

Wouldn't it make more sense to test for capabilities instead of checking specifically for notify-osd?

Jacob Peddicord (jpeddicord) wrote :


Yes, it would, however popup positioning/expiration is not a feature advertised or recognized by any notification daemon.


"It has a setting for whether “message popups” should be “Attached to the status icon” or “In the popup stack”. Notify OSD treats these identically, so when Notify OSD is being used, these settings should not be visible. (Currently, the only way to detect whether positioning is available is to use GetServerInformation to specifically include “notification-daemon” or exclude “Notify OSD”.)"

hackel (hackel) wrote :

It would make more sense for notify-osd to simply allow actions again if the user specifically *chooses* that they want them. This is a real frustration...I don't want to give up the actions completely in order to get a popup notification. This new mentality about what does or does not qualify as a passive notification shouldn't be forced down on users.

Chris Coulson (chrisccoulson) wrote :

Assigning Steve, as per the duplicate

Changed in mail-notification (Ubuntu):
assignee: nobody → Steve Dodier (sidi)
Steve Dodier-Lazaro (sidi) wrote :

It looks like the patch does already everything needed (except hiding the actions associated to the notification incase an action-less daemon is in use ?). Chris, I assigned myself to the other bug because I thought there was no patch yet. I'm gonna let the people who wrote it manage it :)

Changed in mail-notification (Ubuntu):
assignee: Steve Dodier (sidi) → nobody
Chris Coulson (chrisccoulson) wrote :

Thank you for your work there. Some comments on the patch though:

- self_add_actions(self);
+ if ( mn_popups_can_use_actions == 1 )
+ self_add_actions(self);

This should be "if ( mn_popups_can_use_actions (self) == 1 )" shouldn't it?

+ mn_popups_server_caps = notify_get_server_caps();

It seems you leak this list and it's elements here. Each element of the GList should be g_free'd, and the list should be g_list_free'd once you've finished with it.

In fact, it seems that there is already a convenience function in mn-util.c for doing this (mn_g_list_free_deep_custom), so you should use this to free your list.

+ public bool can_use_actions(void)
+ {
+ /* Returns True if notification server will make use of actions, False if not */
+ return mn_popups_server_caps_actions;
+ }

This function should really return a gboolean, to keep it in the same style as the existing code.

+ /* Notify-OSD */
+ if (notify_get_server_info(&notify_name, &notify_vendor, &notify_version, &notify_spec_version))
+ {
+ if (! strcmp(notify_name, "notify-osd"))
+ {
+ gtk_widget_set_sensitive(selfp->popups_position_section_label, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_position_attached_radio, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_position_free_radio, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_expiration_section_label, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_expiration_default_radio, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_expiration_never_radio, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_expiration_after_radio, FALSE);
+ gtk_widget_set_sensitive(selfp->popups_expiration_scale, FALSE);
+ }
+ }

It seems you just make these insensitive, but the spec says that they should not be visible.

Thanks again for your effort there :)

Changed in mail-notification (Ubuntu):
assignee: nobody → Jacob Peddicord (jpeddicord)
status: Triaged → Incomplete
Chris Coulson (chrisccoulson) wrote :

Unsubscribing ubuntu-universe-sponsors for now. Please re-subscribe when ready.


Jacob Peddicord (jpeddicord) wrote :

Here's a modified patch. It applies and theoretically should work, but mail-notification (of any recent version) currently FTBFS in karmic due to something in evolution or gtkhtml:

In file included from /usr/include/evolution-2.28/mail/em-format-html-display.h:28,
                 from /usr/include/evolution-2.28/mail/em-folder-view.h:29,
                 from src/mn-evolution-server.gob:29:
/usr/include/evolution-2.28/mail/em-format-html.h:37:29: error: gtkhtml/gtkhtml.h: No such file or directory
/usr/include/evolution-2.28/mail/em-format-html.h:38:38: error: gtkhtml/gtkhtml-embedded.h: No such file or directory
In file included from /usr/include/evolution-2.28/mail/em-format-html-display.h:28,
                 from /usr/include/evolution-2.28/mail/em-folder-view.h:29,
                 from src/mn-evolution-server.gob:29:
/usr/include/evolution-2.28/mail/em-format-html.h:130: error: expected declaration specifiers or ‘...’ before ‘GtkHTMLEmbedded’
/usr/include/evolution-2.28/mail/em-format-html.h:203: error: expected specifier-qualifier-list before ‘GtkHTML’

Will resubscribe u-u-s once it can be built, but in case anyone wants to try it out, here you go. :)

Ilya Barygin (randomaction) wrote :

I have filed bug 443406 about evolution-gtkhtml problem.

Ernst Sjöstrand (ernstp) wrote :

I think that mail-notification builds better in Lucid now, so then this could be fixed?

Changed in mail-notification (Ubuntu):
status: Incomplete → Confirmed
Klaus Doblmann (moviemaniac) wrote :

I hope it will be fixed properly some day (soon) because at the current state mail-notification is nearly useless with the ugly dialog-popup instead of a real notification.

opax (opax-gm) wrote :

Could comeone sum up what has already been done, please?

Stefano Rivera (stefanor) wrote :

As far as I can tell, this bug has been fixed in the latest development version of Ubuntu - Maverick Meerkat.

If you need a fix for the bug in previous versions of Ubuntu, please follow the instructions for "How to request new packages" at

Changed in mail-notification (Ubuntu):
assignee: Jacob Peddicord (jpeddicord) → nobody
status: Confirmed → Fix Released
Jeremy Nickurak (nickurak) wrote :

Stefano: doesn't list any recent changes... and I don't see anything in notify-osd that suggests this has been fixed. Do you have a pointer to what changed?

Stefano Rivera (stefanor) wrote :

Jeremy: There's a newer version in Maverick, and I simply can't reproduce it on maverick. Please try to do so yourself and reopen this if necessary.

Miguel Mendes Ruiz (migmruiz) wrote :

I'm having this issue on Maverick.

igi (igor-cali) wrote :

I can still confirm wrong behaviour in Maverick and Natty beta2.
It is always reproducible with Gmail accounts (as I described in duplicate

Changed in mail-notification:
status: New → Confirmed
tags: added: maverick natty
igi (igor-cali) on 2011-10-16
tags: added: oneiric
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers