Notification spec issue: Ability to assign an icon *and* an image to a notification

[Christian Hammond]

True. I suppose in this case, we wouldn't necessarily use D-BUS anyway.

Christian

-- 
Christian Hammond - chipx86 at chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com


On Fri, Jun 12, 2009 at 2:26 PM, A. Walton <awalton at gnome.org> wrote:

> On Fri, Jun 12, 2009 at 4:23 PM, Christian Hammond<chipx86 at chipx86.com>
> wrote:
> > I like the idea of using a hint more. As you said, this is a widely used
> > spec at this point, and libnotify/notification-daemon are not the only
> > implementations of this spec. I'd prefer we not break the world.
> >
> > I don't know about it being image_path though. One very common request
> has
> > been to add the ability to send notifications to remote servers. While it
> > hasn't been a priority, I don't want to rule it out altogether. If we
> > replace our icon implementation with image_path, then that will never
> work
> > in a remote case. We'd still have to send the image data.
> >
> > I'd rather image_path be a convenience of libnotify's API rather than
> being
> > in the D-BUS API.
> >
>
> The way I think about it is that if we have a daemon that forwards
> over the network at some point, that it's probably more convenient for
> it to handle the image_file/image_path hint and translate it into
> image_data hint before sending the packet. This is probably how
> sound_file would have to work as well (if an implementation bothered
> to forward those). Both cases reduce bus traffic at the price of a bit
> of server complexity.
>
> -A. Walton
>
> > Christian
> >
> > --
> > Christian Hammond - chipx86 at chipx86.com
> > Review Board - http://www.review-board.org
> > VMware, Inc. - http://www.vmware.com
> >
> >
> > 2009/6/12 A. Walton <awalton at gnome.org>
> >>
> >> 2009/6/12 Aurélien Gâteau <aurelien.gateau at canonical.com>:
> >> > Hello again,
> >> >
> >> > In this mail I would like to address the first issue from the
> >> > notification spec I mentioned in my earlier mail: Ability to assign an
> >> > icon *and* an image to a notification.
> >> >
> >> > KDE notifications need to be able to show an icon and an image at the
> >> > same time. This is because KDE notifications can show an icon to the
> >> > left of the notification summary and an image to the left of the body
> >> > (see attached screenshot).
> >> >
> >> > As of KDE 4.3, KDE uses its own DBus interface, which is quite similar
> >> > to the org.freedesktop.Notifications except the "icon_data" hint is
> >> > named "image_data" and the implementation shows both "app_icon" and
> >> > "image_data" if they are both set.
> >>
> >> I think this is an inconsistency in the spec, since I seem to recall
> >> one page referring to it as image_data and another as icon_data. Image
> >> data is probably better, since it's more general.
> >>
> >> >
> >> > Proposal:
> >> >
> >> > 1. Remove the "icon_data" hint
> >> >
> >> > 2. Add an "image" component to the notification, which would be
> >> > represented as two parameters in the Notify() method: image_type and
> >> > image_data.
> >> >
> >> > image_type: an int which can take the following values, indicating
> what
> >> > image_data contains:
> >> > 0: no icon
> >> > 1: an icon name in a freedesktop.org-compliant icon theme
> >> > 2: path to an existing image on disk
> >> > 3: argb32 data represented as iiay (width, height, array of pixels)
> >> >   (This is a simplified version of the actual "icon_data" hint, which
> >> >   is a bit over-engineered.)
> >> >
> >> > image_data: a byte array whose content is interpreted according to the
> >> > value of image_type.
> >>
> >> The problem with this is that it destroys the backward compatibility
> >> of the spec. Hints are better for a change like this; they're Hints.
> >> Servers can disregard them and clients can send whatever they want as
> >> hints. The way some of them are defined is a bit clunky right now, but
> >> it should be easier to go about adding a hint than it is to change the
> >> declaration of a well-defined, used-everywhere method.
> >>
> >> Furthermore, width, height and array of pixels isn't enough to specify
> >> an image. We'd need to say that all images passed over the bus via
> >> this method have to be in a certain format. The way that its defined
> >> right now, almost any image can be sent (basically it's a serialized
> >> version of GdkPixbuf, an arbitrary image container object). The
> >> advantage to sending almost any image is that clients don't have to
> >> drag in much in the way of image processing, whereas if we do specify
> >> the type, we'll have to convert any image that's not in the right
> >> format to what the server is expecting, which seems ugly to me.
> >>
> >> So, rather than redefining the world, we could just add a new hint:
> >> image_path (somewhere on disk). We leave the app_icon field in the
> >> Notify() method alone since this is the application's icon, and should
> >> be an icon-name as defined in the icon spec, and we say that it's
> >> silly to have both image_path and image_data set and prefer one or the
> >> other, probably image_data since we already have that in the spec,
> >> though really that could be implementation defined too.
> >>
> >> If that's not enough, we can deprecate (not remove) the app_icon field
> >> and add another hint for icon names as an array of strings which might
> >> be a good idea anyways, since this way we could allow fallback icons
> >> to be used in the case an icon theme is missing an icon.
> >>
> >> That way server implementations can decide on what to show and when
> >> and where to show it.
> >>
> >> 2cents, etc.
> >> -A. Walton
> >>
> >> >
> >> > 3. Define the following policy:
> >> >
> >> > """
> >> > A notification can optionally have an image and/or an icon.
> >> >
> >> > An implementation must behave in one of these ways:
> >> > - Never show neither image nor icon.
> >> > - Show image if it is set, otherwise show icon.
> >> > - Show both image and icon.
> >> > """
> >> >
> >> > What do you think about this?
> >> >
> >> > Aurélien
> >> >
> >> > _______________________________________________
> >> > xdg mailing list
> >> > xdg at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/xdg
> >> >
> >> >
> >> _______________________________________________
> >> xdg mailing list
> >> xdg at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/xdg
> >
> >
> > _______________________________________________
> > xdg mailing list
> > xdg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20090612/b41f66f8/attachment.html