Status Notifier specification

Alberts Muktupāvels alberts.muktupavels at
Tue Jan 24 14:18:12 UTC 2017

On Tue, Jan 24, 2017 at 2:07 PM, Marco Martin <notmart at> wrote:

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

What are you trying to say with that? Common sizes...

Carries an ARGB32 binary representation of the icon, the format of icon
> data used in this specification is described in Section Icons
> 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.
> 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.
That is all what specification says. For example:
- qt systray example, has icon pixmap with two sizes - 22 and 64
- creates icon pixmap with one

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

Now items can just put icons with size they want - 128x32px. Nice, right?

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.

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.

You say model/view architecture, can you link to that? Google shows me info
about MVC.
Controller and view more or less is host and model is item, right?

"A *model* 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.

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.

How am I supposed to create host that will look nice and consistent? (I
really want answer...)

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

That does not mean that current specification should not be improved.

and last, always remember what is always quoted in those cases:
> --
> Marco Martin
> _______________________________________________
> xdg mailing list
> xdg at

Alberts Muktupāvels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the xdg mailing list