OpenSC UI notifications never expire in GNOME 3, even after a reboot

[dpward]

Problem Description

When OpenSC generates a UI notification, it will remain in the message tray in GNOME 3 until either the user dismisses it manually (by clicking on it), or until OpenSC sends another notification (which will automatically replace it). Otherwise, the notification will persist even after the system is rebooted. This stale notification may understandably confuse the user and should be avoided.

This behavior for notifications seems to be by design in GNOME 3. Their suggested approach to this situation is used below.

Steps to reproduce

From a GNOME 3 session where a single smart card is inserted into a reader, remove the smart card. A "Smart card removed" notification will briefly overlay on the screen. Afterwards, opening the message tray (by clicking the clock, or pressing Super+M) will show the same notification. (Do not click on the notification.)

Without inserting the smart card again, reboot the system and log in to a GNOME 3 session as the same user. Open the message tray; the previous notification will still appear.

Proposed Resolution

After OpenSC sends a notification using GIO, call g_application_withdraw_notification() later to remove it.

Note that only the opensc-notify daemon should register the GLib Application and call g_application_send_notification(). Currently, this seems to be performed by all processes that use the OpenSC PKCS#11 library. These processes will print this assertion when a notification should be sent:

g_application_send_notification: assertion '!g_application_get_is_remote (application)' failed

[frankmorgner]

The problem is that you can't generically withdraw the notification in sc_notify_close(), because that would effect all applications. You'd have to do it in the opensc-notify binary. I've implemented this stuff for Windows, but on all other platforms the API are just too divergent so that I don't currently want to change this.

The warning with g_application_send_notification happens when two instances are running. This should be implemented by triggering (possible remote) GActions. However, that's something for the next release...

[frankmorgner]

There is no automatic expiration mechanism in gio and manually withdrawing the notification is either too complex or may lead to a notification not beeing showed long enough to be noticed. This, I won't fix.

However, I've added a small workaround to avoid the warning about the remote application, see #1341