Desktop Notification Spec update request: "progress" and "progress-label" hint

[Jan Jurzitza]

Hello all,

I think there should be a progress hint in the notification spec (as in
showing a progress bar inside notifications). Progress bars inside a
notification can be useful in many ways:

* Show file operation status (copy, upload, download)
* Show task status (steps until completion, etc)

But you could also have simple progress indicators (represented as bar,
but not updating) which can display other kinds of information:

* Background setup wizard step indicator
* "Hard drive nearly full" notification with current usage
* Internet quota warning notification with current usage

My suggestions for updating the spec would be the following:

Servers supporting progress bars should add the Server Capability
"progress". Description: Supports showing and updating progress bars.
If returned, the server must support the "progress" and "progress-label"
hints.

Add "progress" of type byte to the standard hints. Valid values would be
integers between incl. 0 and incl. 100 to represent progress. A value of
-1 should be an indeterminate progress bar. For example this would be the
state when starting a file transfer before a connection has been
established. In an ASCII notification server this could be realized using
an animated spinning \|/-

Values over 100 should be clamped to 100, values under 0 (not including
special values such as -1, possibly more in the future) should simply be
discarded and the notification server should not show a progress bar.

Additionally add "progress-label" of type string to the standard hints. If
this is set the progress bar should have a label (inside it or near it)
with the content of this string. If the string is empty the label should
be hidden. If this hint is not specified the server should decide what it
shows as default label. The server must be able to show this string in
some way, if provided.

Updating a progress bar would simply call the existing Notify method and
use the replaces_id parameter. To ensure a fluent desktop experience this
should not be called more than a few times per second. But also to make
sure that no already closed notifications are still trying to be updated
by the client.

An ongoing notification which shows an always updating status should use
the existing resident flag to ensure that it stays open. The existing
actions argument can be used to implement a cancel button by the caller
side.

Adding this to the spec would make file and network operations more
transparent and accessible. Additionally it would standardize DE specific
solutions such as KNotifications/KUI JobView in KDE.

Thanks,

Jan Jurzitza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20171120/bebefb6c/attachment.html>