Notifications spec: Icons

Thu Apr 2 16:13:32 PDT 2009

On Thursday 02 April 2009, Matthew Paul Thomas wrote:
> > 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

knotify4 and the Notifications Plasma::DataEngine. so two places, but both 
near each other in kdebase, and still trivial.

> Have you tried changing org.kde to org.freedesktop temporarily and using
> either notification-daemon or Notify OSD as the notification server?

not much happens :) the two specs are similar but not exactly the same, and 
are just different enough to not work ... which is the point of this whole 
exercise.

the patch to make this change, btw, is +5 -5 lines. :)

speaking of which, i'd really like to see the name changed from 
org.freedesktop.Notifications to org.freedesktop.VisualNotifications. the 
reason for this is that the spec really only talks about, well, visual 
notifications :) there are many other notification mechanisms that are 
possible to implement, and which KDE does implement in knotify.

how much pain would that cause GNOME apps? i'm hoping that this is all held 
inside of libnotify?

> >> 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?

well, that's kind of the problem: it may not be used as an "icon" in the 
visualization and it probably _isn't_ an icon in the sense of "found in an 
icon theme". 

there is, however, app_icon which is an icon and which we use as an icon. 
Olivier has described how this is used, for instance, with kopete 
notifications.

and since icon_data/image_data bitmap data is really intended to be used 
primarily (exclusively?) for images that are not part of the icon theme, using 
the word "icon" is a bit confusing.

compare:

"we have app_icon and icon_data. app_icon is loaded from the icon theme, while 
icon_data is a raw bitmap. one or both may be shown in the visualization, 
depending on if one or both are set as well as how the visualization is 
designed. the app_icon should represent the originating application (from the 
user's POV) while icon_data can be specific to the notificaton contents."

with:

"we have app_icon and image_data. app_icon is loaded from the icon theme, 
while image_data is a raw bitmap. one or both may be shown in the 
visualization, depending on if one or both are set as well as how the 
visualization is designed. the app_icon should represent the originating 
application (from the user's POV) while image_data can be specific to the 
notificaton contents."

the second one is a lot less ambiguous, thanks to not using the word "icon" 
over and over with two slightly different semantics attached.

> > 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.

yep :))

> > 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.

see above ...

> > 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.

assuming that icon_data/image_data should only be used for things that can not 
be found in the icon theme, this is a non-issue. if icon_data/image_data is 
set, then it's pretty safe to assume that there is no themed icon to use. 
(again, this is why i don't like the ambiguity caused by the term "icon_data"; 
it implies something that just isn't true, namely that there is an icon 
somewhere that could be loaded for an equivalent result)

alternatively, we could go "more complex" and:

* allow svg data to be sent across for icon_data/image_data

and/or

* provide a property in org.freedesktop.VisualNotifications that specifies the 
preferred size for the bitmap and applications could, at their discretion, use 
this information when creating bitmaps to send across the bus.

> (We have no interest in showing the application
> icon separately from a more specific one.)

that's cool; it shouldn't be mandatory to show both.

> 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.

that would be interesting to know, indeed.

> >> 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.

ah ... sorry, that was a terminology mixup on my part :) we tend to use the 
term "visualization" for whatever is actually showing a notification (or 
application job, or..) since we have a server that processes notifications but 
may or may not actually perform the final presentation. 

ah, semantics! :)

anyways.. what might also make sense is to warn that images above a certain 
size may be silently dropped and the d-bus communication canceled (to prevent 
DOS, for instance) ...

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090402/60596929/attachment.pgp 