# [solved] virtual/notification-daemon

## schmidicom

Seit kurzem verlangen einige Komponenten von KDE das dieses Teil zwingend installiert sein soll was mich eigentlich weniger stören würde wenn dieses Virtual einem auch die Wahl lassen würde wie das installiert werden soll.

Ich dachte immer das diese Virtuals dazu da sind dem User die Wahl zu lassen wenn mehrere Pakete das selbe können, wieso ist das hier nicht der Fall?Last edited by schmidicom on Mon Jun 10, 2013 9:09 am; edited 1 time in total

----------

## franzf

Schau doch mal ins ebuild rein, unter welchen Bedingungen welche Pakete installiert werden.

hint: virtual/notification-daemon[-gnome] gibt sich auch mit kde-base/knotify zufrieden.

----------

## schmidicom

 *franzf wrote:*   

> Schau doch mal ins ebuild rein, unter welchen Bedingungen welche Pakete installiert werden.
> 
> hint: virtual/notification-daemon[-gnome] gibt sich auch mit kde-base/knotify zufrieden.

 

Nein tut es eben nicht.

Ich habe es mit dem USE Flag "-gnome" und knotify installiert aber trotzdem verlangt es nach libnotify.

EDIT:

Sorry ich habe mich geirrt der libnotify Zwang kommt nicht vom Virtual sondern vom neuen "kde-base/print-manager" ebuild.

```
kde-base/print-manager > app-admin/system-config-printer-gnome > dev-python/notify-python > x11-libs/libnotify
```

Da nützt einem das Virtual ja wirklich viel wenn dann sowas kommt...   :Confused: 

Naja da kann ich ja auch gleich das USE Flag für libnotify setzen denn wenn es schon unbedingt installiert sein muss dann soll es auch benutzt werden.

----------

## franzf

libnotify hat erstmal nichts mit dem virtual zu tun. print-manager hängt nicht von system-config-printer-gnome ab. system-config-printer-kde gabs früher, das hing von s-c-p-common ab, nochdazu gibts nen BLOCK zwischen print-manager und s-c-p-kde.

----------

## schmidicom

 *franzf wrote:*   

> print-manager hängt nicht von system-config-printer-gnome ab.

 

Da scheinen die aber anderer Meinung zu sein: https://bugs.gentoo.org/show_bug.cgi?id=456360#c8

EDIT:

Egal wie man es dreht oder wendet ich werde jetzt dazu genötigt dieses Gnomezeugs zu installieren egal was ich an USE-Flags setze und auch wenn ich jetzt lernen muss damit zu leben so muss es mir dennoch nicht gefallen.

----------

## franzf

Ah, die Abhängigkeit wurde erst gestern eingeführt - wobei laut bug-report an einer besseren Lösung gearbeitet werden sollte. Mal schauen  :Wink: 

----------

## schmidicom

Habe nun, bis die eine bessere Lösung für das Problem finden, einfach dafür gesorgt das mir kein Print Manager und somit auch keine Gnomos mehr installiert werden. Das Webinterface von CUPS ist zur Not ja auch noch da.

```
schmidicom@slap ~ $ cat /etc/portage/package.use/kde 

kde-base/kdeutils-meta -cups
```

Was mich aber immer noch wundert ist warum man ein Virtual für die Notifications erstellt wenn manche Pakete sich offensichtlich trotzdem mit nichts anderem zufrieden geben als libnotify.

----------

## franzf

 *schmidicom wrote:*   

> Was mich aber immer noch wundert ist warum man ein Virtual für die Notifications erstellt wenn manche Pakete sich offensichtlich trotzdem mit nichts anderem zufrieden geben als libnotify.

 

libnotify ist ne lib, mit der man notifications _versendet_, virtual/notification-daemon stellt die Empfängerseite ("daemon") zur Verfügung. Wird wohl über dbus laufen, libnotify abstrahiert das wahrscheinlich weg, die ganzen notification-daemons stellen wahrscheinlich das dbus-interface zur Verfügung.

----------

## schmidicom

Wenn das stimmt dürfte knotify ja nur funktionieren wenn libnotify installiert ist aber bei mir informiert das Benachrichtigungs-Icon (von dem ich jetzt mal annehme das genau das knotify ist) im KDE-Systray brav über alles was so abgeht.

----------

## franzf

 *schmidicom wrote:*   

> Wenn das stimmt dürfte knotify ja nur funktionieren wenn libnotify installiert ist aber bei mir informiert das Benachrichtigungs-Icon (von dem ich jetzt mal annehme das genau das knotify ist) im KDE-Systray brav über alles was so abgeht.

 

Schau mal mit qdbusviewer -> such nach "notif" -> Neben dem org.freedesktop.Notifications (was mMn. von allen über virtual/notification-daemon gewollten Paketen) gibt es noch org.kde.knotify. Die Programme die bei dir Benachrichtigungen anzeigen, werden entweder über die kde-Notification-Schnittstelle arbeiten, oder direkt mit dbus kommunizieren anstatt das über libnotify zu erledigen.

Aber ich muss hier noch sagen, dass ich über das ganze Thema nichts wirkliches weiß, da ich nicht in die Sources geschaut hab. Aber so wie es bei anderen Sachen funktioniert wird es auch hier gehen. Ich hab ein ähnliches Konstrukt schon mit org.freedesktop.ScreenSaver gesehen.

----------

## schmidicom

Dann kocht also so ziemlich jeder Notificationdienst neben der allgemeinen noch sein eigenes kleines Süppchen und das alles in der selben Küche (dbus) und Libnotify baut gleich noch eine Variante ohne dbus auf? Wie sinn frei ist das denn?

Als ich das Virtual sah dachte ich das wenigstens hinten herum alle gleich Arbeiten und nur bei der Front auf die jeweilige Desktopumgebungen angepasst sind aus der sie stammen.

----------

## franzf

libnotify kocht nichts eigenes, es ist ein C-interface um mit dem dbus-Service (org.fd.Notifications)zu kommunizieren. Weils einfacher und sicherer ist als ständig mit den dbus-Interfaces zu hantieren.

Und org.freedesktop.Notifications regelt AFAIK nur notification-popups. knotify macht aber mehr (sound, log, usw.), popups werden an org.fd.Notifications weitergereicht (wer das bei KDE letztlich bei dbus registriert, kann ich gerade nicht sagen, will da aber eigentlich nicht weitersuchen, weils mich grad nicht so brennend interessiert und ich eh kein kde mehr verwende und somit erst alles mögliche an sources ziehen müsste...)

----------

