Notifications spec: Icons

Wed Apr 1 10:49:34 PDT 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bo Thorsen wrote on 01/04/09 11:07:
>...
> There have been a bunch of emails going back and forth between the KDE
> and GNOME people about the notifications spec. It seems everyone wants
> to have a common spec instead of the two current implementations
> (galago and knotify). I think Enlightenment also have an
> implementation of galago, but I'm not certain of this.

A bit of Googling reveals e_modules/notification.
<http://www.mail-archive.com/enlightenment-cvs@lists.sourceforge.net/msg46555.html>
<http://cia.vc/stats/project/e/e_modules/notification>
I don't see contact details for the author ("lok") anywhere, though.

> The goal for these discussions is a single spec that's based on galago,
> but modified to suit the needs of more groups.
> 
> It has been suggested to get this done in time for KDE 4.3, which is
> just over one month away. I don't know about GNOME timing.

How would this affect KDE 4.3? Are KDE developers wanting to implement a
Galago-compliant notification server, and have KNotification feed into
it, in the space of a month? Writing a useful notification server is not
a trivial task. ;-)

> The first problem I'll raise is icons and images. These are mentioned
> several places, and not in a completely coherent way. At the end of
> this mail, you can find the text from all the places where icons or
> images are mentioned in the spec. I hope we can have a debate about
> these changes here, and then I will write up a patch to the spec and
> send it here.
> 
> In a mail (http://lists.freedesktop.org/archives/xdg/2008-April/009401.html) 
> to this list, Aaron Seigo have these change requests concerning icons:
> 
> <quote>
> Issue: the iibiiay format seems a bit overspecified.
> 
> Proposal: always use argb32 data.
> 
> Issue: this part of the spec seems generally underspecificied. there
> is no reference to how icons referenced by name are resolved (the
> theme and naming specs) to name one.
> 
> Proposal: remove this page entirely. all relevant information on icons
> can be found elsewhere in the spec. duplicating information in this
> way just begs for inconsistencies over time.

Handily demonstrating Aaron's point, there is already an inconsistency.
<http://www.galago-project.org/specs/notification/0.9/x344.html> refers
to an "image_data" hint that, as far as I know, doesn't exist.
notification-daemon -- and therefore Gnome applications, and therefore
Notify OSD too -- use "icon_data" instead, as described in
<http://www.galago-project.org/specs/notification/0.9/x207.html> (the
page Aaron proposed for deletion).

> org.freedesktop.Notifications.Notify:
> 
> Issue: app_icon is not necessarily appropriate for a given
> notification. it is defined as "The optional program icon of the
> calling application." the other option is to use the icon_data hint
> instead and ship raw data. there's also abiguities as to the related
> to icon_data, where this icon is defined, etc.
>...
> </quote>
> 
> My main problem with icons is that the spec seems to be confused as
> to what icons the notification server should present. For example, the
> app_icon is called "the notification icon" in section 2, but
> "app_icon" suggests a different meaning. Also, the desktop-entry hint
> can be used to get an icon. So which one should the notification
> server show? While the spec must give some room for server
> implementation freedom, it's hard to write an application when you 
> don't know which icon the server will show.
> 
> Answering (http://lists.freedesktop.org/archives/xdg/2008-April/009409.html) 
> Aaron, Olivier Gouffart writes this about the icons: "icon_data and
> app_icon are different: Take the Kopete online notification: app_icon
> is the kopete icon, while icon_data would be the user's avatar." This
> answer suggests that the application can provide both. But what will
> the server implementations show, then?
>...

Notify OSD uses app_icon if it is present, and if it isn't, icon_data if
it is present. The reason it uses this order (if I remember correctly)
is that app_icon may be SVG, whereas icon_data is always a bitmap. As a
small step toward resolution independence, Notify OSD scales icons (and
everything else) relative to the user's font size. While we recognize
that some icons -- like IM avatars and album art -- will always be
bitmaps, we prefer scalable icons when they are available. So while
Olivier's explanation makes sense, it's not particularly practical for
us. It might be a good idea to introduce a new name for app_icon that
doesn't mention "app".

This leads to a related issue: Where Notify OSD does receive bitmap
icons, we want them to be fairly large, so that it's always scaling them
down rather than scaling them up. Unfortunately, notification-daemon
does not scale images at all (indeed, an easy way to DoS yourself is to
notify-send -i ~/screenshot.png "Help" "I'm stuck in a giant bubble"),
so sending large icons to it is a bad idea. To work around this, we've
provided example code for applications to scale down icons themselves
only when notification-daemon is the active notification server
<https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#blurry>. For
the future, though, it would be helpful if the notification
specification made clear that icons can be any size and that the
notification server is responsible for scaling them to an appropriate size.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknTqSoACgkQ6PUxNfU6ecq2bwCfTujTT/4PXK4mzZxpOGKI968s
1m0An2/Wm4bBgdjw1czH8KKM2ldp+UPh
=mzav
-----END PGP SIGNATURE-----