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

[A. Walton]

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