Status Notifier specification

Alberts Muktupāvels alberts.muktupavels at gmail.com
Mon Jan 23 18:43:31 UTC 2017


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


On Mon, Jan 23, 2017 at 5:49 PM, Marco Trevisan (Treviño) <mail at 3v1n0.net>
wrote:

> I think all this is reasonable
>
> > 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.
>
> Il 09/01/2016 11:36, Alberts Muktupāvels ha scritto:
> > 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
> > <alberts.muktupavels at gmail.com <mailto:alberts.muktupavels at gmail.com>>
> > wrote:
> >
> >     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
>
>


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


More information about the xdg mailing list