Provide a notification history

[José González Gómez]

Please, provide a way to access the notification history.

If some application provides a notification with too much text in it (recently Gnome Do did it in my case) you either read it insanely fast (i've tried with no success, and now I'm cross-eyed) or you miss it.

I finally was able to read the entire message accessing ~/.cache/notify-osd.log after reading the design specification, but I don't think a regular user would be expected to do so. The messages are logged, so I guess it would be easy to provide this kind of functionality.

[Steve Dodier-Lazaro (sidi)]

Such an application would benefit from an improvement of the log.

For instance, if you also store the icon, then with Appname + date + icon + body + title, in a format friendly with parsing, one could display the notifications in a list of columns (see attachment).

I think it should be trivial to code for anyone fluent with GTK+ (ie. not me :p). If someone is up for it, please try to make sure it also fits Xubuntu's default install's dependencies.

[Mark Shuttleworth (sabdfl)]

We're not going to provide a UI for accessing such a journal in 9.10,
but you could try typing "tail ~/.cache/notify-osd.log" to see it in a
terminal window.

Mark

[Steve Dodier-Lazaro (sidi)]

Hello Mark,

I think the whole point of a GUI for that would be to address a need for
end-users who're not friendly with CLI. If such a package was proposed for
inclusion in universe for Karmic, would it be accepted, though ?

[Mark Shuttleworth (sabdfl)]

Steve Dodier wrote:
> I think the whole point of a GUI for that would be to address a need for
> end-users who're not friendly with CLI. If such a package was proposed for
> inclusion in universe for Karmic, would it be accepted, though ?
>
Certainly, an add-on in Universe wouldn't be a problem.

[Steve Dodier-Lazaro (sidi)]

I began implementing a notification historical application.

Mirco, is it possible to add the icon and priority of the notifications in the notify-osd.log file, please ?

[Mirco Müller (macslow)]

Have a look in notify-osd/src/log.c, the call...

guint
bubble_get_urgency (Bubble *self);

... would get you the notifications urgency (0 == low, 1 == normal, 2 == high). But that API is likely to change, due to a planned abstraction split in the way the data in stored.

What exactely do you mean by "icon"? Binary data, (original) size/dimensions, filename? Currently it's not intended to be exposed, so there's no call to aquire this. Also keep in mind there are numerous ways image data can get passed to notify-osd (via DBus). For example it does not necessarily mean image-data was provided via a filename.

On top of all that, nothing of notify-osd's code is meant to be "public API". It's not exposed anywhere. Thus API-compatibility is not guaranteed ... not even internally :)

[Steve Dodier-Lazaro (sidi)]

I would like the file name whenever possible. If there is only a pixbuf,
saving it somewhere would be too costy, so then please put instead a null
path. The historical will just not show any icon for these. If it's really
too much work then nevermind the icon, even if I would prefer having it.

[Steve Dodier-Lazaro (sidi)]

Here is the design of the file i'm parsing in my test code :

 date=YYYY-MM-DDTHH:MM:SS-00:00
 app=Application name
 title=Optional title
 Can be on several lines (can't contain "urgency=", "body=", "icon=")
 urgency=Optional, enum { LOW , NORMAL , CRITICAL }
 icon=Optional, either fullpath (/usr/share/.../foo.svg) or icon name in the theme (foo)
 body=Optional body
 Of course, can be on several lines (but can't contain "date=" ...)

These restrictions sound fair enough to avoid having unparseable notifications, and I think it remains decently readable for humans. If you're ok with it, I'll write the needed changes in notify-osd. Do you mind if I leave it to you to implement a call for an image path when not available ? (it could return "gtk-missing-image" when there was an image but it fails to provide it : pixbuf case).

[David Barth (dbarth)]

Steve, thanks for your comments and proposal. The discussion has drifted to changing the log format to allow you to provide the feature outside of notify-osd, so I'll close the bug and let you propose a branch merge with the patch.