Control: tag -1 + moreinfo Hi Francesco,
(Hint: The reason for the moreinfo tag is near the end of the mail.) Francesco Poli wrote: > > So despite it's name "notification-daemon" looking like being the most > > generic one of all of them, it looks to me as if it does not to > > provide that interface. Very unexpected. [...] > I found [bug #918385](https://bugs.debian.org/918385), which seems to > request this .service file. Thanks! > Sadly, it looks like it's still unaddressed. No comment. > > So > > https://codesearch.debian.net/search?q=Name%3Dorg.freedesktop.Notifications > > leads to this package list: > > > > ukui-notification-daemon > > deepin-notifications > > plasma-workspace > > mako-notifier > > xfce4-notifyd > > mate-notification-daemon > > notify-osd > > But not all of them actually ship a .service file: And actually dunst is missing in that list. Maybe it constructs the .service file I found on my system only during the package build. JFTR: On my system, it seems to be xfce4-notifyd which is running (a few other notification daemons are installed via dependencies, too). So I'm quite sure that it at least works with xfce4-notifyd. IIRC I used dunst in the past for a while, too. So I assume that one still works, too. > [notify-osd](https://packages.debian.org/sid/amd64/notify-osd/filelist) > does not seem to. Indeed, thanks! > On the other hand, > [xfce4-notifyd](https://packages.debian.org/sid/amd64/xfce4-notifyd/filelist) > seems to ship one. That one clearly works. :-) > Should I give systray-mdstat/1.2.0-1 another try, after installing > xfce4-notifyd? Yes, please, at least for the checking other issue which I assume that it is solved with the upload. > Or maybe I should try with: > [ukui-notification-daemon](https://packages.debian.org/sid/amd64/ukui-notification-daemon/filelist) ukui-notification-daemon und deepin-notifications come from cultural (IIRC Russian and Chinese) focussed desktop environments, so I'm not sure what actually makes them different from (an older) GNOME or MATE notification daemon. But yeah, would be interesting to know if and only if it works if such a file is present. Hmmmmm, now that I think about. Could this issue be also the reason for your initially reported issues in #886419, just that Desktop::Notify is less tolerant about this? > > So a short-term workaround seems to depend on only an alternative list > > of these notification daemons. > > Well, please check which of them actually ship the required .service > file, first... Good point, yes. Codesearch just searches through the source code and not every source code in there is used in the actual binary packages. > > Not sure though if it's really related, because the commit message > > seems to sound more like they just disabled starting > > notification-daemon via D-Bus and starred it always by default. > > Mmmh, I do not know for sure, because I am totally ignorant about > notification daemons, Well, yeah, similar here. :-) > but that commit seems to explain that DBus activation causes issues. Well, it more refers to problems, but doesn't really explain anything. Which doesn't really help much in understanding what actually caused them to remove that. > And it seems to say that a .desktop file may be used instead (?). Yes. Which does autostart notification-daemon. But even then: How do they communicate. I though GNOME does nearly everything via D-Bus nowadays. > Is there a way for systray-mdstat to use the .desktop interface, rather > than the .service interface? Well, it's actually the D-Bus interface. D-Bus just happens to use .service files like systemd, but it still seems to be something different. The Perl module Desktop::Notify which I switched to (because it seemed to work better than the old implementation in Glib::Object::Introspection) hasn't seen much love in the past few years, so I suspect it hasn't been adapted to whatever GNOME's notification-daemon now uses to communicate with it. At least the documentation clearly says: This module serves the same purpose as "libnotify", in an object-oriented Perl interface. It is not, however, an interface to "libnotify" itself, but a separate implementation of the specification using Net::DBus. So I strongly assume it only works via D-Bus. A potential third variant, but much more ugly in implementation, would be to rely on passing the messages to /usr/bin/notify-send on the commandline or STDIN, i.e. forking for every notification. Would have the advantage that it uses a more maintained library, at least. (I think.) Then again, libnotify's package descriptions contain the phrase "sends desktop notifications to a notification daemon, as defined in the Desktop Notifications spec". That spec seems to be this one: https://developer.gnome.org/notification-spec/ And this clearly states "all notifications are controlled by a single session-scoped service which exposes a D-BUS interface." So it's still a D-Bus thing after all? Then why doesn't it work with GNOME's very own notification-daemon? Now I'm really confused, as I no more see any reason why Desktop::Notify should not work with GNOME's notification-daemon. > Maybe there's another way to access the org.freedesktop.Notifications > interface, without relying on the .service file. I don't know! Yeah, I think that file just declares what should be started if some tool asks for that interface and nobody listens to that file yet. Which actually leads me to the suspicion that maybe the cause is that notification-daemon is not running on your desktop system for whatever reason (like using a classic X Window Manager which doesn't care about autostart desktop files — which I consider to be a totally valid reason btw. :-) And since you have none of the other notification daemons installed, which could be activated over D-Bus automatically, the reported issue sounds like a probable outcome of that scenario. <moreinfo> Could you check on your system if /usr/lib/notification-daemon/notification-daemon is actually running? </moreinfo> If it is not running, we have found the cause (dependency still missing, though :-) and I probably should catch that case in systray-mdstat. I nevertheless think that this then would be a bug in notification-daemon as it only starts properly depending on the desktop environment. > > Since I'm neither well-versed in GNOME stuff nor in D-Bus stuff, I'm > > bit out of (better) ideas at the moment. > > I am sure you are way more knowledgeable than me about this subject. > It probably just needs a little more research, and you'll figure > everything out! :-) *g* I wouldn't be that sure. I'm more a fan of KISS design in interfaces. And D-Bus is IMHO more the opposite of that. But then again I also prefer to reuse what is already there and don't want to reinvent the wheel either. :-) So despite I prefer lean systems without D-Bus, I still maintain a bunch of packages which use D-Bus. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
