Status Notifier specification

[Alberts Muktupāvels]

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.

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?

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

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.

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

On Mon, Jan 23, 2017 at 10:12 PM, David Edmundson <
david at davidedmundson.co.uk> wrote:

>
> On Mon, Jan 23, 2017 at 7:08 PM, Alberts Muktupāvels <
> alberts.muktupavels at gmail.com> wrote:
>
>>
>>
>> On Mon, Jan 23, 2017 at 8:53 PM, David Edmundson <
>> david at davidedmundson.co.uk> wrote:
>>
>>>
>>> --
>>>>
>>>> Wayland. How item is supposed to open/position context menu? x and y
>>>> parameters are useless, no? Clients in wayland does not know global
>>>> position....
>>>>
>>>
>>> You're right, but this has been phased out as a legacy fallback for
>>> years.
>>>
>>
>> Is that documented somewhere? Or how am I / was supposed to know that.
>>
>>
> It's in the introspection header for our implementation and Qt's
> implementation's.
> I've also copied this onto the wiki just now.
>
>
>> What about Activate, SecondaryActivate? They also have x and y
>> parameters...
>>
> > What if I want provide sound indicator with slider to adjust sound level?
>
>
> They're maybe slightly useless but not entirely.
> Whilst wl_surface doesn't allow you to explicitly set a window position a
> custom compositor extensions could. Kwin has one already for certain
> trusted applications.
>
> In any case that's a communication needed between the client and the
> compositor. I don't think that could be solved with any change to SNI.
>
> David
>
>


-- 
Alberts Muktupāvels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170123/d578633c/attachment-0001.html>