notification-hub

commit

9611dcd469f1f70b890be9183e73c804dcd5cff3

parent

259026a956bcfb14a0e45bcb094d16fed7c39b85

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2020-08-12 07:28

add readme

Diffstat

1 files changed, 76 insertions, 0 deletions

diff --git a/README.md b/README.md

@@ -0,0 +1,76 @@
   -1     1 # Notification Hub
   -1     2 
   -1     3 Distraction-free notification daemon for linux inspired by github.
   -1     4 
   -1     5 -	Notifications are never displayed directly on screen to avoid distraction.
   -1     6 -	If there are notifications, a status indicator is displayed. Clicking on that
   -1     7 	indicator reveals the current notifications in a menu.
   -1     8 -	Notifications are group by application. Only the latest notification for each
   -1     9 	application is shown.
   -1    10 -	Clicking on a notification removes it from the menu.
   -1    11 
   -1    12 ## Dependencies
   -1    13 
   -1    14 -	python3-gi
   -1    15 -	gir1.2-glib-2.0
   -1    16 -	gir1.2-gtk-3.0
   -1    17 -	gir1.2-ayatanaappindicator3-0.1
   -1    18 
   -1    19 ## Known Limitations
   -1    20 
   -1    21 -	Only supports `app_name`, `replaces_id`, and `summary`. Everything else
   -1    22 	(expiration, icons, HTML body, actions) is ignored.
   -1    23 -	Lies about the supported features to other software to avoid fallbacks (e.g.
   -1    24 	in firefox)
   -1    25 -	Does not display the summary of the previous notification if the latest one is
   -1    26 	closed.
   -1    27 -	Applications rarely close notifications that are no longer relevant (e.g.
   -1    28 	because you have just looked at the your new messages). So you have to close
   -1    29 	them manually.
   -1    30 
   -1    31 ## Background
   -1    32 
   -1    33 I hate notifications. They are totally distracting and sometimes even leak
   -1    34 private information when they display the entirety of a private message while
   -1    35 someone else is looking at my screen.
   -1    36 
   -1    37 Status indicators on the other hand are great. Tiny bits of information that I
   -1    38 can access at any time. Am I connected to the network? Are my speakers muted?
   -1    39 What is my current keyboard layout? Do I have unread messages? So easy to see
   -1    40 and completely non-distracting. A changing status indicator is just subtle
   -1    41 enough to be noticeable while staying out of the way.
   -1    42 
   -1    43 Unfortunately, while the linux world has pretty much settled on a [standard for
   -1    44 notifications](https://developer.gnome.org/notification-spec/), status
   -1    45 indicators are in peril:
   -1    46 
   -1    47 X11 protocols such as
   -1    48 [`_NET_WM_STATE_DEMANDS_ATTENTION`](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html)
   -1    49 and [system
   -1    50 tray](https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-latest.html)
   -1    51 have been out of fashion for a while, but wayland will probably be the final
   -1    52 blow. Ubuntu toyed with something called [app
   -1    53 indicators](https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators)
   -1    54 for a while which was picked up by KDE and is now called
   -1    55 [StatusNotifierItem](https://freedesktop.org/wiki/Specifications/StatusNotifierItem/).
   -1    56 The original GTK implementation is now maintained by a small team under the name
   -1    57 of [AyatanaAppIndicator](https://sunweavers.net/blog/node/67). Gnome on the
   -1    58 other hand decided to [ditch status indicators
   -1    59 completly](https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/). In
   -1    60 their official documentation they even suggest to use notifications instead of
   -1    61 status indicators. Preposterous!
   -1    62 
   -1    63 Irony aside, I can understand much of the criticism towards both the old system
   -1    64 tray and status indicators in general. I also agree that there are many cases
   -1    65 where status indicators are not the right tool and something else should be used
   -1    66 instead. But still, for some cases they are just perfect.
   -1    67 
   -1    68 What ever the reasons, we now have a situation where application authors have no
   -1    69 clear guidance on how to implement status indicators and therefore don't do it.
   -1    70 So if you disable notification (because you hate them) and a chat program has no
   -1    71 status indicator, there is just no way to get notified of new messages.
   -1    72 
   -1    73 The silver lining here is that notifications and status are somewhat related.
   -1    74 For example, you can have a status indicator that only displays whether there
   -1    75 are any new notifications. This project is an experiment around exactly that
   -1    76 idea.