Notifications spec: Icons

Thu Apr 2 03:09:15 PDT 2009

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

Aaron J. Seigo wrote on 01/04/09 21:52:
>...
> we actually did all that work in KDE 4.2. KNotification talks to
> knotify4, and knotify4 forwards it on via dbus if the notification is
> supposed to show up as a passive popup and an appropriate service is
> registered on the session bus.
>...
> all that's left is to sort out the details of the notifications spec,
> tweak the dbus interface we use as needed (the two files that would
> need modifying are both in kdebase ...) and then
> s,org.kde,org.freedesktop,g
> 
> so the implementation stuff is only an hour or two's work at this
> point for myself or one of the other Plasma devs.

Awesome. I guess that means for any non-feature (e.g. syntax) changes in
the spec, you need to change only one thing (knotify4), instead of
changing a bunch of applications and libraries as Gnome would need to do.

Have you tried changing org.kde to org.freedesktop temporarily and using
either notification-daemon or Notify OSD as the notification server?
That would be an interesting interoperability test.

>...
>> 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).
> 
> erg ... icon_data is not a great name since there's really nothing
> that says this image will be used as an icon.

icon_data has "icon" in its name. The spec section describing it is
titled "Icons". And that section begins "A notification can optionally
have an icon specified by the Notification Icon field or by the
icon_data hint."

Do you have any suggestions for how it could be made clearer?

> as we followed the specification when implementing this in plasma, we
> put in support for image_data and not icon_data.

notification-daemon and Notify OSD "followed the specification" in this
respect too, we just followed a different part. :-) So, the
inconsistency does need fixing one way or another.

> it would be easy to switch it to icon_data, but it would be nice to
> have the better name if possible.

In what respect would "image_data" be better? The term "icon" is fairly
well-known amongst the target audience for this protocol, I think, and
"icon_data" is used in many applications already.

>...
>> 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
> 
> should this be the other way around? if the application has an icon
> name it can use, it should set app_icon and not set icon_data. if a
> bitmap is supplied, there is probably a reason for that (e.g. it's
> something like a user's avatar or some other image created at
> runtime), so the server should use that by default? the app_icon would
> then be a fallback so that when showing a notification it would be
> possible (though not required, of course) for the visualization to
> show the originating application as well.

That would require some other way for applications to provide scalable
non-application icons. (We have no interest in showing the application
icon separately from a more specific one.)

I'll see if we can collect some data on how many notifications currently
specify app_icon, how many set it to something other than the
application icon, how many set icon_data, how many set both, and how
many set neither.

>> 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".
> 
> hm.. icon_name and icon_data?

That would make more sense.

>> 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.
> 
> how does the server know what an appropriate size is?
>...

Because it's the server deciding how large the notification presentation
is (for example, how large notification bubbles are). The server can do
things like take screen size into account in a single place, rather than
applications doing that redundantly and inconsistently.

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

iEYEARECAAYFAknUjsUACgkQ6PUxNfU6ecqRHACfQFnJktPkbu1Es6DKbfCJ61eE
6NoAnRERMM08RIi6XXJjs/HABdHiSKY1
=Y5Qj
-----END PGP SIGNATURE-----