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

[marmarek]

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

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

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

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

[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 (#1297).
• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

[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 (#1297).
• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

[marmarek]

On Thu, Oct 08, 2015 at 10:44:05AM -0700, Patrick Schleizer wrote:

• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

Not "until" - something needs to sent those notifications either to some
notification daemon, or to our "Centralized Tray Notifications".
kdialog apparently doesn't do that, notify-send (or other tools like
this) does.

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?

[marmarek]

On Thu, Oct 08, 2015 at 10:44:05AM -0700, Patrick Schleizer wrote:

• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

Not "until" - something needs to sent those notifications either to some
notification daemon, or to our "Centralized Tray Notifications".
kdialog apparently doesn't do that, notify-send (or other tools like
this) does.

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?

[marmarek]

BTW check if notify-send would also work on plain debian - AFAIR KDE
notification service also listens on that standard protocol.

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?

[marmarek]

BTW check if notify-send would also work on plain debian - AFAIR KDE
notification service also listens on that standard protocol.

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]

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

[adrelanos]

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

[adrelanos]

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.

Yes. Very useful. I would very much like to implement this. But I can't.
notify-send(1) can't replace an existing notification:
https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135

[adrelanos]

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.

Yes. Very useful. I would very much like to implement this. But I can't.
notify-send(1) can't replace an existing notification:
https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135

[marmarek]

On Thu, Oct 08, 2015 at 10:51:47AM -0700, Patrick Schleizer wrote:

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Hmm, just checked and here (Qubes dom0 with KDE) it looks exactly like
the other KDE notifications. For that to work, "Notifications" widget
needs to be added to panel. Anyway probably not worth further
investigation.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

We plan to implement it transparently to the VM applications. It will
look like any other notification daemon, so for example notify-send (and
any other application using standard API) would just work.

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?

[marmarek]

On Thu, Oct 08, 2015 at 10:51:47AM -0700, Patrick Schleizer wrote:

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Hmm, just checked and here (Qubes dom0 with KDE) it looks exactly like
the other KDE notifications. For that to work, "Notifications" widget
needs to be added to panel. Anyway probably not worth further
investigation.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

We plan to implement it transparently to the VM applications. It will
look like any other notification daemon, so for example notify-send (and
any other application using standard API) would just work.

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?

[andrewdavidwong]

Just doing a routine check: Is it still correct that @rootkovska is assigned to this issue?

[andrewdavidwong]

Just doing a routine check: Is it still correct that @rootkovska is assigned to this issue?

[marmarek]

No.

[marmarek]

No.

[marmarek]

Also, there is a PoC written by @v6ak, linked and described in that qubes-devel thread

[marmarek]

Also, there is a PoC written by @v6ak, linked and described in that qubes-devel thread

[andrewdavidwong]

Thanks. Updated.

[andrewdavidwong]

Thanks. Updated.

[andrewdavidwong]

@v6ak, are you still working on this?

[andrewdavidwong]

@v6ak, are you still working on this?

[v6ak]

I am not working on this for multiple reasons. In short, I consider this to be much work for relatively low benefit:

• I really liked the idea of KDE notifications. However, KDE 4 as whole does not seem to be stable enough for me. As a result, I use just KWin with XFCE apps, and I am no longer using KDE notifications.
• I probably have too low notification rate to get some collisions regularly.
• Some basic implementation can actually worsen the UX, because the notifications would miss buttons etc.
• It is not as trivial as it originally looked like. (See the discussion thread.) Well, I would probably implement it if I felt this as a major UX pain point for me (because this is still not sooo much work…), but this is not the case.

So, I am able to discuss this if someone feels unsure about the design or my notes, but I don't plan to do this myself.

[v6ak]

I am not working on this for multiple reasons. In short, I consider this to be much work for relatively low benefit:

• I really liked the idea of KDE notifications. However, KDE 4 as whole does not seem to be stable enough for me. As a result, I use just KWin with XFCE apps, and I am no longer using KDE notifications.
• I probably have too low notification rate to get some collisions regularly.
• Some basic implementation can actually worsen the UX, because the notifications would miss buttons etc.
• It is not as trivial as it originally looked like. (See the discussion thread.) Well, I would probably implement it if I felt this as a major UX pain point for me (because this is still not sooo much work…), but this is not the case.

So, I am able to discuss this if someone feels unsure about the design or my notes, but I don't plan to do this myself.

[andrewdavidwong]

@v6ak: Understood. Thank you for all of your hard work so far and for your willingness to help anyone who might choose to take over on this!

[andrewdavidwong]

@v6ak: Understood. Thank you for all of your hard work so far and for your willingness to help anyone who might choose to take over on this!

[marmarek]

It should be useful for any desktop environment - almost every DE have its own notification daemon, which uses the same D-Bus API. Anyway indeed UX impact isn't big here.
On the other hand, having this service, and probably one more for simple confirmations would allow having gpg backend domains without X server running at all (-> much lower memory footprint).

[marmarek]

It should be useful for any desktop environment - almost every DE have its own notification daemon, which uses the same D-Bus API. Anyway indeed UX impact isn't big here.
On the other hand, having this service, and probably one more for simple confirmations would allow having gpg backend domains without X server running at all (-> much lower memory footprint).

[v6ak]

Yes, it should work for (almost) any DE, I just found it more useful with KDE than with XFCE. Provided that there are no concurrent notifications from different VMs (I've found such cases rare) and all the VMs use the same notification daemon, there might be nothing wrong with UX. The KDE notification daemon provides some Android-like notification history (I like the idea, though I've not verified if it is really useful), which makes sense to have just in one VM.

The GPG backend is a good point. Maybe it could be the starting point for wide deployment (i.e. enabled by default), as it is a bounded usecase, so most UX issues should be immediately apparent.

Also unikernels might want to use it. However, I don't feel it would be good to start there, because this could lead to a protocol that is not well-mappable to libnotify.

However, centralized notifications might be a prerequisite for implementing a reasonable focus-stealing protection.

[v6ak]

Yes, it should work for (almost) any DE, I just found it more useful with KDE than with XFCE. Provided that there are no concurrent notifications from different VMs (I've found such cases rare) and all the VMs use the same notification daemon, there might be nothing wrong with UX. The KDE notification daemon provides some Android-like notification history (I like the idea, though I've not verified if it is really useful), which makes sense to have just in one VM.

The GPG backend is a good point. Maybe it could be the starting point for wide deployment (i.e. enabled by default), as it is a bounded usecase, so most UX issues should be immediately apparent.

Also unikernels might want to use it. However, I don't feel it would be good to start there, because this could lead to a protocol that is not well-mappable to libnotify.

However, centralized notifications might be a prerequisite for implementing a reasonable focus-stealing protection.

[jpouellet]

xref use case: https://groups.google.com/d/msg/qubes-devel/uhF11aVolUA/PIo-JcSCAQAJ

[jpouellet]

xref use case: https://groups.google.com/d/msg/qubes-devel/uhF11aVolUA/PIo-JcSCAQAJ