Status Notifier specification

[Marco Martin]

On Monday 23 January 2017, Alberts Muktupāvels wrote:
> In short - SNI is broken by design...
> 
> As application author you know nothing - you can provide some properties,
> but you can not know if anyone will use them. You can implement methods,
> but you can not now if any of them will be called. There is no way to know
> if host even shows your item...
> 
> As host you need to deal with random stuff items provide. One provides
> icon-name, next one has icon-pixmap with size 24x24px... One item provides
> symbolic icon, but other not. As bonus one item will use dbus menu, next
> one will use only available methods. You have zero options to control it.

applications only expose a model of data, as every model/view they should know 
nothing about whatever the representation will be.
Model which perhaps yes could be better described in the spec.

> For example desktop notification specification has GetCapabilities method.
> So before sending notification you have option to check if it will be
> displayed correctly and/or send other data/info if you know that something
> you relay on is not supported by current implementation.
> 
> Since we can not guarantee that ContextMenu, Activate and SecondaryActivate
> will correctly work we should remove them. So if dbus menu is implemented
> in all active SNI implementations then how about making things simple? Icon
> + menu.
> 
> How application developers are supposed to debug problems? As example -
> ubuntu that only shows items that have dbus menu. I know it, but others
> might not. When you create item without menu it is not displayed - why? Did
> I forgot to set Title? Or maybe it requires WindowId property with valid
> xwindow?

that's a decision by ubuntu, which i think is not really compliant, but it's 
up to them.

> And no - looking at all existing implementations is not answer. If I can
> not write working sni item by just reading specification then there are
> problems - that is not good specification...

then it means that the specification document isn't exaustive enough so it 
should be improved/expanded (the Menu property has been added now btw)

> Would not be better if we would have some item <-> host communication? When
> item is registered host checks required properties. If there is problem it
> sends message to item - missing property x or something like that, I will
> not show you. So now when I debug SNI i will got message/error - required
> property Menu is not set / valid.
> 
> Previously mentioned thing - icons. Why item should send over dbus icon
> pixmaps at random size when host could ask for icon at needed size? What if
> hosts displays icon at 44px? If SNI has icon-name then it might be ok, but
> with icon pixmaps it will be scaled down or in worst case up.

it's not random sizes, it's the sizes the applications knows about, which 
historically have been well specified (16, 22, 32, 48, 64, 128)
https://portland.freedesktop.org/doc/xdg-icon-resource.html

and how in toolkits icon objects are usually defined: a container of multiple 
images at different sizes, which this is a dbus serialization.

the model is never a 1:1 communication, but it's a typical model/view 
architecture, with one NotificationItem and N hosts, which the application 
instanciating the NotificationItem doesn't know anything about, neither how 
many there are nor where they are on the screens (or if it's a graphical 
representation at all). That's the central point in the architecture, it won't 
change.
typical use case (used a lot by our users, apparently) is a system with 2 
monitors, with panels on both screens, the screens with very different 
resolution/DPI, will need icons of different size.
of course if the view has an odd size it won't be able to use the perfect 
pixmap of the perfect size, but the application just can't ship icons of every 
possible size, no matter what the dbus protocol is.

> Can we agree on improvements / changes? By using versioned dbus names we
> will have option to support old and new specification...

It's almost 10 years of this, and some XEmbed-based implementations are still 
there. how do you think adding yet another set of incompatibilities will go 
down?

and last, always remember what is always quoted in those cases: 
https://xkcd.com/927/

-- 
Marco Martin