Linuxでは、通知はどのように機能しますか？

通知サーバーとは何ですか？どのような役割を果たしますか？

一般的な用語で、仕える人クライアントが何らかの方法で（ネットワーク経由でもローカルIPCメカニズムでも）接続するプログラムです。したがって、通知サーバーは、クライアントからの「通知」要求を受け入れ、クライアントに代わって通知を表示するプログラムです。

通知クライアントとは何ですか？どのような役割を果たしますか？

すべてのプログラム使用通知サーバーは「通知クライアント」になります。繰り返しますが、これは通知関連の用語ではなく、アーキテクチャ全体に関するものです。

この通知送信を使用して通知をポップアップとして表示できますか？ （まあ、）お客様ですか？

はい、この場合は顧客です。その目的は主にあなた通知ポップアップを表示することができます。アプリは独自のプロセスで直接同じ操作を実行できるため、通知は実行されません。

通知デーモンとは何ですか？

通知サーバーとまったく同じです。

「デーモン」という用語にはいくつかの異なる意味があります。それは何かを指します。背景「サーバー」であるかどうかにかかわらずサービス - しかし、この場合、実際の通知ポップアップ表示を担当するプログラムはサーバーでありデーモンです（デーモンのようにバックグラウンドで実行され、サービスのように要求を受け取るためです）。 ）。

そしてlibnotifyの役割は何ですか？

これは、通知クライアントが使用しているIPCメカニズムの詳細（およびプロトコルバージョンの違い）を抽象化するために使用できる小さなライブラリです。このプログラムはD-Busとインターフェースに関する知識を必要としませんnotify_notification_new(...)。

（つまり、多くのアプリケーションは、必要な呼び出しを実行するためにlibdbusを使用するなど、直接通信を実装することを選択します。これは非常に単純なプロトコルなので、両方のオプションは同じように一般的です）。

クライアント（例：libnotify）と通知サーバーの間で使用されるプロトコルを「libnotifyプロトコル」と誤って呼び出すことがよくあります。

ユーザー（私）の観点から見ると、これら2つの美学に違いはありますか？私の言葉は、通知が実行されているときと他の通知が異なるように見えることを発見したということです。

それは文字通り違い。そのアイデアは、各デスクトップ環境（GNOME、KDEなど）には、そのデスクトップ環境に合わせてカスタマイズされたポップアップ（外観、設定、動作など）を表示する独自の通知サーバーがあることです。

（別のデーモンである必要はありません。たとえば、GNOMEとAwesomeWMでは、通知サービスはデスクトップシェル自体によって提供されます。）

ところで、「彼らはどんなサービスを提供していますか？」という質問がここで起こります。なぜなら、彼らは他のツールが通知を送って良い方法で表示できるのを待っているようです。

はい、しかし、「他のツールが通知を送信するのを待つ」は、何かを「提供する」とは見なされません。サービスが必ずしも一部のデータを返す必要はありません。システムにはある程度一方向のサービスがたくさんあります。つまり、そのタスクは次のようになります。する代わりに何か返品何。

とにかく、通知に対してカスタムアクションを実行するにはどうすればよいですか？このすべてのコンテンツをインポートし、独自のシェルスクリプトを持ちたいとしましょう。 ~/notifications ファイルに追加するだけです。これは私が独自の通知サーバーを作成するという意味ですか？それとも顧客ですか？または何をか。

クライアントが通信するための合意された方法である通知プロトコルを実装している場合は、独自の「通知サーバー」を作成します。ほとんどのLinuxシステムの事実上の標準は、D-Busを介して "org.freedesktop.Notifications"インターフェースを実装することです。これを実装すると、通知サーバーがあります。

（シェルスクリプトにするのは本当に難しいですが、インターフェイスが2つ程度の関数で構成されていることを考慮すると、PythonやPerlでは10行以内で可能です。）

まず、通知デーモンを使ってみました。インストール後にのみ機能しません。通知の送信を正常に呼び出すには、手動で起動するか（/usr/lib/notification-daemon-1.0/notification-daemonを実行することを意味します）、何らかの方法で自動的に起動するか、/usr/shareにファイルを作成する必要があります。 /dbus-1/services/org.freedesktop.Notifications.serviceには次の内容が含まれています。

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

このファイルは意図的に存在しません。これは、1つのプログラムだけがこの特定のサービスを提供することを意味するからです。実際、プログラムにはそれぞれ独自の通知サービスを持つ複数のデスクトップ環境がインストールされている可能性があり、D-Busには1つのプログラム実装に優先順位を付けるメカニズムはありません。または別の。

したがって、他の多くのD-Busサービスは自動起動が可能ですが、ほとんどの通知サーバーは「誤った」デスクトップ環境で起動するように選択されないように意図的に自動起動できません。デスクトップ環境は、適切なサービスを「手動で」開始するように設計されています。たとえば、~/.xinitrcこれによりサービスから起動できます。

それからDunstを試しましたが、一度インストールすると通知転送が機能するという意味で動作しました。私はこれが基本的に最初にinform-sendが呼び出されたときに起こると思います。しかし、どうやってそれをしますか？

上記と全く同じアプローチを使用します。そのパッケージには実際にD-Bus .serviceファイルが含まれています。

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

[D-BUSサービス]
名前=org.freedesktop.Notifications
実行=/usr/bin/dunst
SystemdService=dunst.service

唯一の違いは、実際のファイルが提供する必要があるサービス名にちなんで命名されないことです（dbus-daemonは「ユーザー」サービスにこの要件を適用しません）。

私も非常に薄く、しわがないように見えるstatnotを見ましたが、前の段落を参照してstatnotを使用することは、xmobarによって公開されたいくつかのAPIを呼び出すupdate_text関数を介して設定を書く必要があることを意味するように感じます。 xmonad。これにより、一度にどのくらいの通知を表示するかを制御できなくなります。

これは避けられないようです。カスタムロジックが必要な場合は、カスタムロジックを作成する必要があります。

たとえば、私は通知デーモンを書いたことがあります。dzen2を使う「ポップアップ」で。 Notify() メソッドで目的のロジックを実装できます。

通知がどのように機能するか、通知を操作するために「プレーヤー」がどのようにやり取りするかについての明確な理解は実際にはないと思います。

技術的に言うと（実装に関係なく）通知を処理するためのデーモン（通知の受信と処理など）、他のプロセスがそのデーモンに通知を渡す方法、通知がどのような形式であるべきかに関するプロトコル（標準）アプリケーションからデーモンに渡されたデータは処理可能に見えます。

ほとんどのLinuxデスクトップ環境のギャップを埋めるには:

• 通知デーモンがあります（多くのデスクトップ環境（Gnomeなど）は、ユーザーセッションを介して実行される独自の実装を取得します。他の場合は、小さいデスクトップを使用する場合はこのデーモンサービスの通知を設定する必要があります。実装があります。後者の中で、MakoはWaylandデスクトップの名前で指定されました。
• 通知デーモン（デスクトップ通知仕様に準拠している場合）はD-BUSインターフェース（D-BUSはプロセス間通信を可能にするメッセージングシステム）を公開し、他のプロセスはこのインターフェースを使用してデーモンに通知を送信します。
• デスクトップ通知仕様は、デーモンが有効な通知に渡されると予想されるものと、通知が持つことができるパラメーターを定義します。 （この内容をより深く理解するには、仕様を読むことをお勧めします。デスクトップ通知仕様)

そしてlibnotifyの役割は何ですか？

簡単に言えば、Libnotifyは、デスクトップ通知仕様に準拠した通知をこの規格に準拠した通知デーモンに送信する機能を提供するライブラリです。 Linuxでデスクトップ通知をサポートする必要があるアプリケーションを構築する場合は、libnotifyを使用してこれを達成できます。