Status Notifier specification

[Alberts Muktupāvels]

Hi!

I think that it is time to update this specification. Here is list with
changes that I propose.

1. Specification.
=================

1.1. Currently we have three components - Watcher, Host and Item. We should
rename specification from 'Status Notifier Item' to 'Status Notifier'.

1.2. Current implementations use org.kde.* for dbus names. While this
specification is not used by all desktop environments it is not used only
by kde either. We should start using org.freedesktop.* for dbus names.

1.3. We should start to use versioned dbus interface names.

2. Watcher.
===========

2.1. Make method, property and signal names shorter by removing
'StatusNotifier' part from names.

2.2. RegisterHost method, change arguments to:
- bus_name (s) - the bus name of Status Notifier Host or empty to use
sender;
- object_path (o) - the object path of Status Notifier Host.

2.3. RegisterItem method, change arguments to:
- bus_name (s) - the bus name of Status Notifier Item or empty to use
sender;
- object_path (o) - the object path of Status Notifier Item.

2.4. RegisteredItems property, change type from 'as' to 'a(so)' - bus name
and object path for each registered item.

2.5. ProtocolVersion property, remove it.

2.6. Rename 'StatusNotifierHostRegistered' signal to 'HostsChanged'. Should
be emitted when new host is registered or existing disappears.

2.7. ItemRegistered signal, change arguments to:
- bus_name (s) - the bus name of Status Notifier Item that was registered;
- object_path (o) - the object path of Status Notifier Item that was
registered;

2.8. ItemUnregistered signal, change arguments to:
- bus_name (s) - the bus name of Status Notifier Item that was unregistered;
- object_path (o) - the object path of Status Notifier Item that was
unregistered;

Watcher should use:
- org.freedesktop.StatusNotifier1.Watcher as bus name and interface name;
- /org/freedesktop/StatusNotifier1/Watcher as object path.

Improvements over existing interface:
- removed unused property;
- ability to create/register multiple items/hosts from one connection
(currently it is not possible because there can not be two objects with
same path);
- hosts and items are not required to create separate bus name.

Updated dbus interface is added as attachment.

3. Host.
========

Host should use:
- org.freedesktop.StatusNotifier1.Host as interface name.

Optionally (not required, but similar to current specification):
- org.freedesktop.StatusNotifier1.Host-{pid}-{id} as bus name where {pid}
is process id and {id} is unique identifier starting with 1 (was
'org.kde.StatusNotifierHost-{pid}');
- /org/freedesktop/StatusNotifier1/Host{id} as object path where {id} is
unique identifier starting with 1 (was '/StatusNotifierHost').

4. Item.
========

4.1. Drop all New* signals and use PropertiesChanged to get new/changed
data.

4.2. New property - IconThemePath (type=s). An additional path to add to
the theme search path to find the icons. It looks like this is used by
current implementations.

4.3. New property - ItemIsMenu (type=b). I have seen this in interface
files, does anyone knows if this is really used? If not then it should not
be included in updated spec.

4.4. New property - Menu (type=o). Object path to dbus menu
(com.canonical.dbusmenu interface). This is used at least by ubuntu.

Maybe type could be changed from o to s? So if there is no menu it could be
set to empty string instead of non-existent path?

4.5. Specification should mention which properties are required and which
ones are optional.

Item should use:
- org.freedesktop.StatusNotifier1.Item as interface name.

Optionally (not required, but similar to current specification):
- org.freedesktop.StatusNotifier1.Item-{pid}-{id} as bus name where {pid}
is process id and {id} is unique identifier starting with 1 (was
'org.kde.StatusNotifierItem-{pid}-{id}');
- /org/freedesktop/StatusNotifier1/Item{id} as object path where {id} is
unique identifier starting with 1 (was '/StatusNotifierItem').

Updated dbus interface is added as attachment.

[Alberts Muktupāvels]

Hi,

few extra changes...

1. Watcher.
===========

1.1. Two extra methods - UnregisterHost and UnregisterItem with bus_name
and object_path as arguments.

1.2. Previously I wrote that bus_name could be also empty, but now I think
that it would be better to just require valid bus name - unique or
well-known.

2. Item.
===========

2.1. Scroll method - change orientation argument from string to unsigned
int (u). 0 = Horizontal, 1 = Vertical. Unrecognised orientation should be
considered equal to Horizontal.

2.2. Category - change property type from string to unsigned int. 0 =
ApplicationStatus, 1 = Communications, 2 = System Services, 3 = Hardware.
Unrecognised category should be considered equal to ApplicationStatus.

2.3. Status - change property type from string to unsigned int. 0 =
Passive, 1 = Active, 2 = Needs Attention. Unrecognised status should be
considered equal to Passive.


On Sun, Dec 6, 2015 at 4:01 PM, Alberts Muktupāvels <

Post by Alberts Muktupāvels
Hi!
I think that it is time to update this specification. Here is list with
changes that I propose.
1. Specification.
=================
1.1. Currently we have three components - Watcher, Host and Item. We
should rename specification from 'Status Notifier Item' to 'Status
Notifier'.
1.2. Current implementations use org.kde.* for dbus names. While this
specification is not used by all desktop environments it is not used only
by kde either. We should start using org.freedesktop.* for dbus names.
1.3. We should start to use versioned dbus interface names.
2. Watcher.
===========
2.1. Make method, property and signal names shorter by removing
'StatusNotifier' part from names.
- bus_name (s) - the bus name of Status Notifier Host or empty to use
sender;
- object_path (o) - the object path of Status Notifier Host.
- bus_name (s) - the bus name of Status Notifier Item or empty to use
sender;
- object_path (o) - the object path of Status Notifier Item.
2.4. RegisteredItems property, change type from 'as' to 'a(so)' - bus name
and object path for each registered item.
2.5. ProtocolVersion property, remove it.
2.6. Rename 'StatusNotifierHostRegistered' signal to 'HostsChanged'.
Should be emitted when new host is registered or existing disappears.
- bus_name (s) - the bus name of Status Notifier Item that was registered;
- object_path (o) - the object path of Status Notifier Item that was
registered;
- bus_name (s) - the bus name of Status Notifier Item that was
unregistered;
- object_path (o) - the object path of Status Notifier Item that was
unregistered;
- org.freedesktop.StatusNotifier1.Watcher as bus name and interface name;
- /org/freedesktop/StatusNotifier1/Watcher as object path.
- removed unused property;
- ability to create/register multiple items/hosts from one connection
(currently it is not possible because there can not be two objects with
same path);
- hosts and items are not required to create separate bus name.
Updated dbus interface is added as attachment.
3. Host.
========
- org.freedesktop.StatusNotifier1.Host as interface name.
- org.freedesktop.StatusNotifier1.Host-{pid}-{id} as bus name where {pid}
is process id and {id} is unique identifier starting with 1 (was
'org.kde.StatusNotifierHost-{pid}');
- /org/freedesktop/StatusNotifier1/Host{id} as object path where {id} is
unique identifier starting with 1 (was '/StatusNotifierHost').
4. Item.
========
4.1. Drop all New* signals and use PropertiesChanged to get new/changed
data.
4.2. New property - IconThemePath (type=s). An additional path to add to
the theme search path to find the icons. It looks like this is used by
current implementations.
4.3. New property - ItemIsMenu (type=b). I have seen this in interface
files, does anyone knows if this is really used? If not then it should not
be included in updated spec.
4.4. New property - Menu (type=o). Object path to dbus menu
(com.canonical.dbusmenu interface). This is used at least by ubuntu.
Maybe type could be changed from o to s? So if there is no menu it could
be set to empty string instead of non-existent path?
4.5. Specification should mention which properties are required and which
ones are optional.
- org.freedesktop.StatusNotifier1.Item as interface name.
- org.freedesktop.StatusNotifier1.Item-{pid}-{id} as bus name where {pid}
is process id and {id} is unique identifier starting with 1 (was
'org.kde.StatusNotifierItem-{pid}-{id}');
- /org/freedesktop/StatusNotifier1/Item{id} as object path where {id} is
unique identifier starting with 1 (was '/StatusNotifierItem').
Updated dbus interface is added as attachment.
--
Alberts Muktupāvels

[Alberts Muktupāvels]

This specification really needs update...

--

What was reason to add all *Pixmap properties? Only hosts knows icon size.
It is completely useless if item provides IconPixmap with 16, 24, 34, 64,
128 (as example) if host at the end needs icon at 256px size or 96px. So
there must be one or other way to host request icons at specific size!

While typically there will be one host we should remember that there might
be multiple hosts that requires icons at different sizes.

So item might have following extra changes:
- IconChanged signal, to let host know when item wants to show
different/other icon.
- IconType property, name or pixmap so host knows if item will provide
pixmaps or simply icon names.
- GetIconPixmap method to request icon at needed size

This definitely needs more thinking, but current properties with more or
less random size icon pixmaps should go away.

--

One more thing related to icons - I think there must be a way to request
symbolic or non-symbolic icons. Currently there is no way to do that -
items can provide whatever they want, but I want be able to decide what
type of icons host will display. And if item can not / does not want to
provide symbolic icon - host should have all rights to not show such item.

--

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

I think all this is reasonable

Post by Alberts Muktupāvels
4.2. New property - IconThemePath (type=s).
An additional path to add to the theme search path to find the icons.
It looks like this is used by current implementations.

Probably this could even be an array to support multiple paths.

Post by Alberts Muktupāvels
Hi,
few extra changes...
1. Watcher.
===========
1.1. Two extra methods - UnregisterHost and UnregisterItem with bus_name
and object_path as arguments.
1.2. Previously I wrote that bus_name could be also empty, but now I
think that it would be better to just require valid bus name - unique or
well-known.
2. Item.
===========
2.1. Scroll method - change orientation argument from string to unsigned
int (u). 0 = Horizontal, 1 = Vertical. Unrecognised orientation should
be considered equal to Horizontal.
2.2. Category - change property type from string to unsigned int. 0 =
ApplicationStatus, 1 = Communications, 2 = System Services, 3 =
Hardware. Unrecognised category should be considered equal to
ApplicationStatus.
2.3. Status - change property type from string to unsigned int. 0 =
Passive, 1 = Active, 2 = Needs Attention. Unrecognised status should be
considered equal to Passive.
On Sun, Dec 6, 2015 at 4:01 PM, Alberts Muktupāvels
Hi!
I think that it is time to update this specification. Here is list
with changes that I propose.
1. Specification.
=================
1.1. Currently we have three components - Watcher, Host and Item. We
should rename specification from 'Status Notifier Item' to 'Status
Notifier'.
1.2. Current implementations use org.kde.* for dbus names. While
this specification is not used by all desktop environments it is not
used only by kde either. We should start using org.freedesktop.* for
dbus names.
1.3. We should start to use versioned dbus interface names.
2. Watcher.
===========
2.1. Make method, property and signal names shorter by removing
'StatusNotifier' part from names.
- bus_name (s) - the bus name of Status Notifier Host or empty to
use sender;
- object_path (o) - the object path of Status Notifier Host.
- bus_name (s) - the bus name of Status Notifier Item or empty to
use sender;
- object_path (o) - the object path of Status Notifier Item.
2.4. RegisteredItems property, change type from 'as' to 'a(so)' -
bus name and object path for each registered item.
2.5. ProtocolVersion property, remove it.
2.6. Rename 'StatusNotifierHostRegistered' signal to 'HostsChanged'.
Should be emitted when new host is registered or existing disappears.
- bus_name (s) - the bus name of Status Notifier Item that was registered;
- object_path (o) - the object path of Status Notifier Item that was
registered;
- bus_name (s) - the bus name of Status Notifier Item that was unregistered;
- object_path (o) - the object path of Status Notifier Item that was
unregistered;
- org.freedesktop.StatusNotifier1.Watcher as bus name and interface name;
- /org/freedesktop/StatusNotifier1/Watcher as object path.
- removed unused property;
- ability to create/register multiple items/hosts from one
connection (currently it is not possible because there can not be
two objects with same path);
- hosts and items are not required to create separate bus name.
Updated dbus interface is added as attachment.
3. Host.
========
- org.freedesktop.StatusNotifier1.Host as interface name.
- org.freedesktop.StatusNotifier1.Host-{pid}-{id} as bus name where
{pid} is process id and {id} is unique identifier starting with 1
(was 'org.kde.StatusNotifierHost-{pid}');
- /org/freedesktop/StatusNotifier1/Host{id} as object path where
{id} is unique identifier starting with 1 (was

'/StatusNotifierHost').

Post by Alberts Muktupāvels
4. Item.
========
4.1. Drop all New* signals and use PropertiesChanged to get
new/changed data.
4.2. New property - IconThemePath (type=s). An additional path to
add to the theme search path to find the icons. It looks like this
is used by current implementations.
4.3. New property - ItemIsMenu (type=b). I have seen this in
interface files, does anyone knows if this is really used? If not
then it should not be included in updated spec.
4.4. New property - Menu (type=o). Object path to dbus menu
(com.canonical.dbusmenu interface). This is used at least by ubuntu.
Maybe type could be changed from o to s? So if there is no menu it
could be set to empty string instead of non-existent path?
4.5. Specification should mention which properties are required and
which ones are optional.
- org.freedesktop.StatusNotifier1.Item as interface name.
- org.freedesktop.StatusNotifier1.Item-{pid}-{id} as bus name where
{pid} is process id and {id} is unique identifier starting with 1
(was 'org.kde.StatusNotifierItem-{pid}-{id}');
- /org/freedesktop/StatusNotifier1/Item{id} as object path where
{id} is unique identifier starting with 1 (was

'/StatusNotifierItem').

Post by Alberts Muktupāvels
Updated dbus interface is added as attachment.
--
Alberts Muktupāvels

[Alberts Muktupāvels]

--

Post by Alberts Muktupāvels
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.

What about Activate, SecondaryActivate? They also have x and y parameters...

What if I want provide sound indicator with slider to adjust sound level?

Clients should pass the menu as a property "Menu" which is a DBus object

path to a com.canonical.dbusmenu interface.
This is currently implemented in all active implementations of SNI.
David

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

On Mon, Jan 23, 2017 at 7:08 PM, Alberts Muktupāvels <

On Mon, Jan 23, 2017 at 8:53 PM, David Edmundson <

--

Post by Alberts Muktupāvels
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

[Marco Martin]

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

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.

Post by Alberts Muktupāvels
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.

Post by Alberts Muktupāvels
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)

Post by Alberts Muktupāvels
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.

Post by Alberts Muktupāvels
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/

[Alberts Muktupāvels]

Post by Alberts Muktupāvels

Post by 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

Post by Alberts Muktupāvels
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

Post by Alberts Muktupāvels
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.

Post by Alberts Muktupāvels
For example desktop notification specification has GetCapabilities

method.

Post by Alberts Muktupāvels
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

Post by Alberts Muktupāvels
you relay on is not supported by current implementation.
Since we can not guarantee that ContextMenu, Activate and

SecondaryActivate

Post by Alberts Muktupāvels
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

Post by Alberts Muktupāvels
+ 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

Post by Alberts Muktupāvels
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.

Post by Alberts Muktupāvels
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)

Post by Alberts Muktupāvels
Would not be better if we would have some item <-> host communication?

When

Post by Alberts Muktupāvels
item is registered host checks required properties. If there is problem

it

Post by Alberts Muktupāvels
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

Post by Alberts Muktupāvels
hosts displays icon at 44px? If SNI has icon-name then it might be ok,

but

Post by Alberts Muktupāvels
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

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

Carries an ARGB32 binary representation of the icon, the format of icon

Post by Alberts Muktupāvels
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
- https://github.com/jjk-jacky/statusnotifier/ creates icon pixmap with one
size

"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

Post by Alberts Muktupāvels
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.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
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...)

Post by Alberts Muktupāvels
Can we agree on improvements / changes? By using versioned dbus names we

Post by Alberts Muktupāvels
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.

Post by Alberts Muktupāvels
https://xkcd.com/927/
--
Marco Martin
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[Alberts Muktupāvels]

On Tue, Jan 24, 2017 at 4:18 PM, Alberts Muktupāvels <

Post by Alberts Muktupāvels
Carries an ARGB32 binary representation of the icon, the format of icon

Post by Alberts Muktupāvels
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.

Apparently even this part is not clear from specification - ARGB32 data

can be premultiplied. So one item provides premultiplied data, next one not
premultiplied. How hosts should deal with that?