Como funcionam as notificações no Linux?

O que é um servidor de notificação e para que serve?

Na terminologia geral, um servidor é um programa ao qual os clientes se conectam de alguma forma (seja pela rede ou por mecanismos IPC locais). O servidor de notificação é, portanto, um programa que aceita solicitações de "mostrar uma notificação" de clientes e mostra notificações em seu nome.

O que é um cliente de notificação e o que ele faz?

Qualquer programa que utilize um servidor de notificação torna-se um "cliente de notificação". Novamente, este não é um termo específico de notificação; trata-se da arquitetura geral.

O que é esse envio de notificação que posso usar para fazer uma notificação aparecer? É o (bem, um) cliente?

Sim, é um cliente neste caso. Seu objetivo é principalmente apenas para que você possa fazer notificações aparecerem; os aplicativos não o executam porque podem executar as mesmas operações diretamente em seu próprio processo.

O que é um daemon de notificação?

Exatamente a mesma coisa que um servidor de notificação.

O termo 'daemon' tem um significado um pouco diferente; refere-se a qualquer tipo de serviço em segundo plano , seja um "servidor" ou não - mas neste caso, o programa responsável por mostrar os pop-ups de notificação reais é um servidor e um daemon ao mesmo tempo (pois é executado em background como um daemon e aceita solicitações como um serviço).

E qual é o papel do libnotify?

É uma pequena biblioteca que pode ser usada por clientes de notificação, para abstrair as especificidades do mecanismo IPC usado (bem como as diferenças entre as versões do protocolo). Em vez de precisar saber sobre D-Bus e interfaces, o programa simplesmente faz notify_notification_new(...).

(Dito isto, muitos aplicativos optam por implementar as comunicações diretamente, por exemplo, usando libdbus para fazer as chamadas necessárias – é um protocolo bastante simples, então ambas as opções são provavelmente igualmente comuns.)

O protocolo usado entre um cliente (como libnotify) e um servidor de notificação também é frequentemente chamado erroneamente de "protocolo libnotify".

E da perspectiva do usuário (eu), a diferença entre os dois é estética? Quero dizer, quando um está em execução e o outro em execução, vejo que a notificação parece diferente

Essa é literalmente a diferença. A ideia é que cada ambiente de área de trabalho (GNOME, KDE, etc.) tenha seu próprio servidor de notificação que mostre pop-ups personalizados para aquele ambiente de área de trabalho – aparência, configurações, comportamento, etc.

(Pode não ser necessariamente um daemon separado; por exemplo, no GNOME e no AwesomeWM, o serviço de notificação é fornecido pelo próprio shell da área de trabalho.)

Aliás, aí vem a pergunta “o que eles estão servindo?”, porque me parece que eles estão apenas esperando que alguma outra ferramenta lhes envie notificações, para que possam mostrá-las de uma forma simpática.

Sim, mas "esperar que alguma outra ferramenta envie notificações" é o que conta como "servir" algo. Como resultado, um serviço não precisa necessariamente retornar alguns dados – há muitos serviços em qualquer sistema que são mais ou menos unilaterais, ou seja, cujo trabalho é fazer algo em vez de retornar algo.

De qualquer forma, e se eu quiser fazer coisas personalizadas com as notificações? Digamos que eu queira obter todos eles e ter meu próprio script de shell que, digamos, apenas os anexe em um arquivo ~/notifications. Isso significaria que estou escrevendo meu próprio servidor de notificação? Ou cliente? Ou o que?

Você estaria escrevendo seu próprio "servidor de notificação" se ele implementasse o protocolo de notificação, ou seja, o método acordado pelo qual os clientes se comunicam com ele. Para a maioria dos sistemas Linux, o padrão de fato é implementar a interface "org.freedesktop.Notifications" através do D-Bus – se você implementá-la, você terá um servidor de notificação.

(Embora seja realmente difícil fazer isso através de um script de shell, isso pode ser feito em cerca de 10 linhas de Python ou Perl, visto que a interface consiste em aproximadamente duas funções.)

Eu tentei primeiro com o daemon de notificação. Isso não funciona apenas após a instalação. Para que uma chamada para notificar-enviar seja bem-sucedida, é necessário iniciá-la (isso significa executar /usr/lib/notification-daemon-1.0/notification-daemon) manualmente, iniciá-la automaticamente de alguma forma ou criar um arquivo em /usr/ compartilhe/dbus-1/services/org.freedesktop.Notifications.service com este conteúdo

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/notification-daemon-1.0/notification-daemon

A ausência deste arquivo é deliberada, pois implica que existe apenas um programa fornecendo este serviço específico – enquanto na realidade pode-se ter vários ambientes de desktop instalados, cada um com seu próprio serviço de notificação, e o D-Bus não possui mecanismo para priorizar um. implementação ou outro.

Portanto, embora muitos outros serviços D-Bus possam ser iniciados automaticamente, a maioria dos servidores de notificação deliberadamente não o são, de modo que não seriam escolhidos para serem iniciados no ambiente de desktop "errado". O ambiente de área de trabalho destina-se a iniciar "manualmente" o serviço apropriado, por exemplo, você pode iniciá-lo a partir do seu computador, ~/.xinitrcse fizer isso.

Aí tentei o dunst, mas que, assim que instalado, simplesmente funciona, no sentido de que notificar-enviar simplesmente funciona. Acho que isso ocorre fundamentalmente porque ele se inicia na primeira chamada para notificar-enviar (o que significa que inicialmente tive a impressão de que funcionava também depois de desinstalá-lo; isso porque o processo dust estava em execução), mas como funciona? que?

Ele usa exatamente o mesmo método que você descreveu acima – seu pacote na verdade inclui um arquivo .service D-Bus:

$ cat /usr/share/dbus-1/services/org.knopwob.dunst.service

[Serviço D-BUS]
Nome=org.freedesktop.Notificações
Exec=/usr/bin/dunst
SystemdService=dunst.service

A única diferença é que o arquivo real não recebe o nome do serviço que supostamente fornece (o dbus-daemon não impõe esse requisito para serviços de "usuário").

Também dei uma olhada no statnot, que parece muito fino e sem frescuras, mas com referência ao parágrafo anterior, parece que usar statnot ainda significaria que eu ainda teria que escrever uma configuração que, por meio da função update_text , chama alguma API que xmobar ou xmonad expõe. Dessa forma eu não teria controle sobre, digamos, quantas notificações desejo mostrar por vez.

Isso parece ser inevitável. Se você quiser uma lógica customizada, precisará escrever uma lógica customizada.

Por exemplo, uma vez escrevi um daemon de notificação que usa dzen2 como "pop-up". Você pode implementar qualquer lógica que desejar no método Notify().

Acho que não tenho uma compreensão muito clara de como as notificações funcionam e quais são os "jogadores" interagindo para que as notificações funcionem:

Tecnicamente (e independente de implementação), você precisará de pelo menos um daemon para lidar com notificações (por exemplo, recebê-las e processá-las), uma maneira de outros processos entregarem notificações ao referido daemon e um acordo (por exemplo, um padrão) sobre o que a notificação os dados passados ​​de um aplicativo para o daemon parecem poder ser processados.

Para preencher os espaços em branco na maioria dos ambientes de desktop Linux:

• Há um daemon de notificações (muitos ambientes de desktop como o Gnome trazem suas próprias implementações que são iniciadas com uma sessão do usuário; em outros casos, se você usar um desktop mais minimalista, talvez seja necessário configurar um serviço de daemon de notificação para isso; existem diferentes implementações deste último disponíveis, mako, para citar um para desktops wayland).
• O daemon de notificação (se estiver em conformidade com a especificação de notificações de desktop) expõe uma interface D-BUS (D-BUS é um sistema de passagem de mensagens que permite a comunicação entre processos) que é então usada por outros processos para enviar notificações ao daemon.
• A especificação de notificações da área de trabalho define o que o daemon espera que seja passado como uma notificação válida e quais parâmetros uma notificação pode ter (recomendo a leitura da especificação para se aprofundar nisso: Especificação de notificações da área de trabalho )

E qual é o papel do libnotify?

Libnotify é, simplesmente, uma biblioteca que fornece funcionalidade para enviar notificações compatíveis com a Especificação de Notificações de Área de Trabalho para um daemon de notificações que também está em conformidade com este padrão. Se você estiver construindo um aplicativo que suporte notificações de desktop no Linux, você pode usar libnotify para conseguir isso.