<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 2:07 PM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com" target="_blank">notmart@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-">On Monday 23 January 2017, Alberts Muktupāvels wrote:<br>
> In short - SNI is broken by design...<br>
><br>
> As application author you know nothing - you can provide some properties,<br>
> but you can not know if anyone will use them. You can implement methods,<br>
> but you can not now if any of them will be called. There is no way to know<br>
> if host even shows your item...<br>
><br>
> As host you need to deal with random stuff items provide. One provides<br>
> icon-name, next one has icon-pixmap with size 24x24px... One item provides<br>
> symbolic icon, but other not. As bonus one item will use dbus menu, next<br>
> one will use only available methods. You have zero options to control it.<br>
<br>
</span>applications only expose a model of data, as every model/view they should know<br>
nothing about whatever the representation will be.<br>
Model which perhaps yes could be better described in the spec.<br>
<span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-"><br>
> For example desktop notification specification has GetCapabilities method.<br>
> So before sending notification you have option to check if it will be<br>
> displayed correctly and/or send other data/info if you know that something<br>
> you relay on is not supported by current implementation.<br>
><br>
> Since we can not guarantee that ContextMenu, Activate and SecondaryActivate<br>
> will correctly work we should remove them. So if dbus menu is implemented<br>
> in all active SNI implementations then how about making things simple? Icon<br>
> + menu.<br>
><br>
> How application developers are supposed to debug problems? As example -<br>
> ubuntu that only shows items that have dbus menu. I know it, but others<br>
> might not. When you create item without menu it is not displayed - why? Did<br>
> I forgot to set Title? Or maybe it requires WindowId property with valid<br>
> xwindow?<br>
<br>
</span>that's a decision by ubuntu, which i think is not really compliant, but it's<br>
up to them.<br>
<span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-"><br>
> And no - looking at all existing implementations is not answer. If I can<br>
> not write working sni item by just reading specification then there are<br>
> problems - that is not good specification...<br>
<br>
</span>then it means that the specification document isn't exaustive enough so it<br>
should be improved/expanded (the Menu property has been added now btw)<br>
<span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-"><br>
> Would not be better if we would have some item <-> host communication? When<br>
> item is registered host checks required properties. If there is problem it<br>
> sends message to item - missing property x or something like that, I will<br>
> not show you. So now when I debug SNI i will got message/error - required<br>
> property Menu is not set / valid.<br>
><br>
> Previously mentioned thing - icons. Why item should send over dbus icon<br>
> pixmaps at random size when host could ask for icon at needed size? What if<br>
> hosts displays icon at 44px? If SNI has icon-name then it might be ok, but<br>
> with icon pixmaps it will be scaled down or in worst case up.<br>
<br>
</span>it's not random sizes, it's the sizes the applications knows about, which<br>
historically have been well specified (16, 22, 32, 48, 64, 128)<br>
<a href="https://portland.freedesktop.org/doc/xdg-icon-resource.html" rel="noreferrer" target="_blank">https://portland.freedesktop.o<wbr>rg/doc/xdg-icon-resource.html</a><br></blockquote><div><br></div><div>What are you trying to say with that? Common sizes...<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Carries an ARGB32 binary representation of the icon, the format of icon 
data used in this specification is described in Section Icons<br><p>All the icons can be transferred over the bus by a particular 
serialization of their data, capabe of representing multiple resolutions
 of the same image or a brief aimation of images of the same size.</p>

<p>Icons are transferred in an array of raw image data structures of 
signature a(iiay) whith each one describing the width, height, and image
 data respectively. The data is represented in ARGB32 format and is in 
the network byte order, to make easy the communication over the network 
between little and big endian machines.</p></blockquote></div><div>That is all what specification says. For example:<br>- qt systray example, has icon pixmap with two sizes - 22 and 64<br></div><div>- <a href="https://github.com/jjk-jacky/statusnotifier/" target="_blank">https://github.com/jjk-jacky/s<wbr>tatusnotifier/</a> creates icon pixmap with one size<br></div><div><br></div><div>"Well specified" apparently does not work. Since you linked to icon specification that says icons must be square, why there is width & height? It should have been enough to use just size.<br><br></div><div>Now items can just put icons with size they want - 128x32px. Nice, right?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
and how in toolkits icon objects are usually defined: a container of multiple<br>
images at different sizes, which this is a dbus serialization.<br>
<br>
the model is never a 1:1 communication, but it's a typical model/view<br>
architecture, with one NotificationItem and N hosts, which the application<br>
instanciating the NotificationItem doesn't know anything about, neither how<br>
many there are nor where they are on the screens (or if it's a graphical<br>
representation at all). That's the central point in the architecture, it won't<br>
change.<br>
typical use case (used a lot by our users, apparently) is a system with 2<br>
monitors, with panels on both screens, the screens with very different<br>
resolution/DPI, will need icons of different size.<br>
of course if the view has an odd size it won't be able to use the perfect<br>
pixmap of the perfect size, but the application just can't ship icons of every<br>
possible size, no matter what the dbus protocol is.<span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-"><br></span></blockquote><div><br></div><div>And what is wrong with my idea that host asks for icon at needed size? What wrong that view ask model for data it needs? Item might have svg file, so it might generate icon at needed size. Previously mentioned last common size - 128 will be 256 on HiDPI screen.<br></div><div><br></div><div>You say model/view architecture, can you link to that? Google shows me info about MVC.<br><br></div><a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller" target="_blank">https://en.wikipedia.org/wiki/<wbr>Model%E2%80%93view%E2%80%<wbr>93controller</a><br></div><div class="gmail_quote">Controller and view more or less is host and model is item, right? <br></div><div class="gmail_quote"><br>"A <i>model</i> stores data that is retrieved according to commands from the controller and displayed in the view." So as controller I say - I need icon at size 64 and it should be symbolic. Models then gives to view icon - here is icon at 64, but sorry it is not symbolic. View/Controller then can decide what to do - display or not.<br><div><br></div><div>If I want to show SNI items as popup window, with icons at 256px sizes? What result I will get? Technically you are allowed to do whatever you want, but in reality it does not work.<br></div><div><br></div><div>How am I supposed to create host that will look nice and consistent? (I really want answer...)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-">
> Can we agree on improvements / changes? By using versioned dbus names we<br>
> will have option to support old and new specification...<br>
<br>
</span>It's almost 10 years of this, and some XEmbed-based implementations are still<br>
there. how do you think adding yet another set of incompatibilities will go<br>
down?<br></blockquote><div><br></div><div>That does not mean that current specification should not be improved.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
and last, always remember what is always quoted in those cases:<br>
<a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a><br>
<span class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail-HOEnZb"><font color="#888888"><br>
--<br>
Marco Martin<br>
______________________________<wbr>_________________<br>
xdg mailing list<br>
<a href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/xdg" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/xdg</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="m_5329613740692477157gmail-m_-3714357384946301079gmail-m_139537618033580690gmail_signature"><div dir="ltr">Alberts Muktupāvels<br></div></div>
</div></div>