Centralized Tray Notifications

[marmarek]

Reported by joanna on 18 Aug 2014 14:59 UTC
A simple qubes.TrayNotification service in Dom0/GUI domain that would be trigerable by agents in each VM (which would register as default tray notifcator). The protocol should be trivial -- just a fixed-size string, sanitized by the server in the usual way (same as we do for Windows titles, etc).

Migrated-From: https://wiki.qubes-os.org/ticket/889

Historical information about contributors

Community Dev: @v6ak, @nastaziya, @fepitre
Partial PoC: https://groups.google.com/d/msg/qubes-devel/1Lzv9SQCzFc/4gKx06iKRD4J
Discussion: https://groups.google.com/d/topic/qubes-devel/1Lzv9SQCzFc/discussion

[marmarek]

Related discussion: https://groups.google.com/forum/#!searchin/qubes-devel/libnotify/qubes-devel/1Lzv9SQCzFc/2Jk5bPzF9tcJ

[adrelanos]

Milestone justification:
This feature is important for Whonix usability. (See #1267.)

[adrelanos]

Likely a follow up issue:
One passive popup blocks another one. Example:
kdialog --passivepopup test1 ; kdialog --passivepopup test2
I.e. as long as the user does not click the first passive popup to make it go away, the second one will not be shown. So by not clicking the first one, the second passive popup will be lost unseen. A usability issue.
I am saying this, because until this ticket is implemented, I cannot implement what we planned for Whonix. (Which is "No more Tor bootstrap progress bar. + "Tor bootstrap in progress." passive poupup + "Tor bootstrap done." passive popup.) @bnvk @mfc

[marmarek]

On Thu, Oct 08, 2015 at 08:22:34AM -0700, Patrick Schleizer wrote:

Likely a follow up issue:

I think this one is orthogonal to the ticket main topic. See below.

One passive popup blocks another one. Example:
kdialog --passivepopup test1 ; kdialog --passivepopup test2
I.e. as long as the user does not click the first passive popup to make it go away, the second one will not be shown. So by not clicking the first one, the second passive popup will be lost unseen. A usability issue.

So... use something that doesn't have this behaviour. kdialog --passivepopup is some KDE specific mechanism, not using any standard
API (especially not freedesktop notification protocol). So even if we
implement "Centralized Tray Notifications", this wont affect kdialog
behaviour. Try notify-send.

Note that some notification daemons have some limits on simultaneous
notifications (like gnome-notification-daemon - 21, currently we use
mate-notification-daemon, which AFAIR have much larger limit). What
happens with additional notifications is implementation specific, but in
most cases are lost, not queued.

One additional thing - maybe useful here - freedesktop notification
protocol supports retracting notifications (independent of setting some
timeout). So if one message, like "Connecting..." is no longer relevant,
it can be retracted (CloseNotification dbus method) and/or replaced
(another Notify with replaces_id set) with another one.
AFAIR not all implementations support this feature. Also not sure if our
"Centralized Tray Notifications" will pass such messages.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

• kdialog looks nice in plain Debian jessie. Nicely integrated into systray. Looks weird in Qubes. Not sure that's worth an issue.
• Posted a related issue, notify-send parameter --expire-time broken in Qubes (notify-send parameter --expire-time broken in Qubes #1297).
• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!