True. I suppose in this case, we wouldn&#39;t necessarily use D-BUS anyway.<br><br>Christian<br><br clear="all">-- <br>Christian Hammond - <a href="mailto:chipx86@chipx86.com">chipx86@chipx86.com</a><br>Review Board - <a href="http://www.review-board.org">http://www.review-board.org</a><br>

VMware, Inc. - <a href="http://www.vmware.com">http://www.vmware.com</a><br>
<br><br><div class="gmail_quote">On Fri, Jun 12, 2009 at 2:26 PM, A. Walton <span dir="ltr">&lt;<a href="mailto:awalton@gnome.org">awalton@gnome.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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