Centralized Tray Notifications #889

Open
marmarek opened this Issue Mar 8, 2015 · 19 comments

Projects

None yet

5 participants

@marmarek
Member
marmarek commented Mar 8, 2015

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

@rootkovska rootkovska was assigned by marmarek Mar 8, 2015
@marmarek marmarek added this to the Release 2.1 (post R2) milestone Mar 8, 2015
@adrelanos
Member

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

@adrelanos
Member

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
Member
marmarek commented Oct 8, 2015

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
Member
  • 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
Member
marmarek commented Oct 8, 2015

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
Member
marmarek commented Oct 8, 2015

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
Member

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 adrelanos added a commit to adrelanos/msgcollector that referenced this issue Oct 8, 2015
@adrelanos adrelanos - use notify-send in Qubes by default, because that looks better in Q…
…ubes than kdialog (thanks to @marmarek for the suggestion) - QubesOS/qubes-issues#889 (comment)

- fixed usage of notify-send, it uses milliseconds rather than seconds (thanks to @marmarek for the suggestion)
- refactoring
87d0d8f
@adrelanos
Member

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
Member
marmarek commented Oct 8, 2015

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 marmarek modified the milestone: Release 4.0, Release 3.1 Feb 8, 2016
@andrewdavidwong
Member

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

@rootkovska rootkovska was unassigned by marmarek Apr 21, 2016
@marmarek
Member

No.

@marmarek
Member

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

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Apr 21, 2016
@andrewdavidwong andrewdavidwong Update "Centralized Tray Notifications" with PoC 2cd8937
@andrewdavidwong
Member

Thanks. Updated.

@andrewdavidwong
Member

@v6ak, are you still working on this?

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 9, 2016
@andrewdavidwong andrewdavidwong Update #889 883d8d3
@v6ak
v6ak commented Jun 12, 2016

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
Member

@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 andrewdavidwong added a commit that referenced this issue Jun 12, 2016
@andrewdavidwong andrewdavidwong Update #889 status 8ffd12a
@marmarek
Member

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

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 12, 2016
@andrewdavidwong andrewdavidwong Update #889 89ec20f
@v6ak
v6ak commented Jun 12, 2016

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.

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 13, 2016
@andrewdavidwong andrewdavidwong Update #889 6f6dc98
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment