The following warning message appears in the session log on a fresh boot:
(wrapper-2.0:499): xfce4-notification-plugin-WARNING **: 14:37:47.115: Unable to check for unread messages: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.xfce.Notifyd was not provided by any .service files
Notification logging is not enabled.
Version: 0.8.2
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Yes, this will happen if you use systemd startup instead of dbus activation for the daemon. No way around it, really.
Not sure why systemd startup is even an option here; dbus activation is better & more reliable. I may remove the former just to avoid issues like this.
Same thing then; XDG autostart will start notifyd after the panel plugin gets started, because xfce4-session will start the panel in a higher priority level than XDG autostart items.
I'm not sure the rationale in e604b499 for setting this as the default is all that great...
After thinking about this a bit more, there shouldn't be any harm in always installing the dbus auto-activation service file, regardless if notifyd is started via XDG autostart or systemd. Autostart/systemd will take care of starting it, but if it needs to be started earlier, like in this case (which is probably now the common case), then it'll still get started properly.
Either way, the warning is more or less harmless; the next time you try to open the plugin menu, it'll attempt again to contact notifyd, and will succeed.
For some reason the first two are tied together, when they probably shouldn't be; we can use dbus auto-activation without systemd, and we could also have it started via systemd if we don't use dbus auto-activation.
The rationale in e604b499 for making XDG autostart the default is mostly reasonable. Sure, there's a slight lag on first notification (which maybe I should try to fix; xfce4-notifyd shouldn't take that long to start!), and there's always the possibility that another notification daemon could get started instead of xfce4-notifyd if (for example) the KDE notification service is installed.
So I think what I want to do is always unconditionally install the dbus auto-activation files. (Well, I'll provide a configure switch to disable it in case people don't want it for some reason.) Then, additionally, we can have the option to install the XDG autostart file for people who are concerned about the above issues.
One thing I'm not clear on is how to handle systemd here: if the systemd integration is enabled, will it automatically start xfce4-notifyd with the session, or does it have to be done explicitly? That's not entirely clear to me, as the systemd service unit is marked Type=dbus, and I'm not sure if systemd will automatically start those, or will assume auto-activation is going to do it. Need to investigate that some more.
IIRC /lib/systemd/user is always the correct location, unless it's an incredibly non-standard system. Assuming a prefix of /usr, $(prefix)/lib/systemd/user would be incorrect on any system that does not have a merged / and /usr. If you have a link to information that contradicts my understanding here, please point me to it.
At any rate, there's a configure option to set a custom path if anyone needs it.
Ah, seems we're both mistaken. While /lib/... is correct for systemd system units, /usr/lib/... is the place for user units. (While $(prefix) will often be /usr, we can't assume that.) From the manpage:
System Unit Search Path /etc/systemd/system.control/* /run/systemd/system.control/* /run/systemd/transient/* /run/systemd/generator.early/* /etc/systemd/system/* /etc/systemd/system.attached/* /run/systemd/system/* /run/systemd/system.attached/* /run/systemd/generator/* ... /lib/systemd/system/* /run/systemd/generator.late/* User Unit Search Path ~/.config/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/transient/* $XDG_RUNTIME_DIR/systemd/generator.early/* ~/.config/systemd/user/* $XDG_CONFIG_DIRS/systemd/user/* /etc/systemd/user/* $XDG_RUNTIME_DIR/systemd/user/* /run/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator/* $XDG_DATA_HOME/systemd/user/* $XDG_DATA_DIRS/systemd/user/* ... /usr/lib/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator.late/*
Hmm, interesting. Well, we still can't use $(prefix), as the notifyd install prefix need not be the same as the systemd install prefix. I'm going to leave it as-is; again, users/packagers can override if they need to.
I find it a bit strange not to honor the installation prefix for D-Bus and systemd services. It is certainly possible to specify what is needed via --with-dbus-service-dir and --with-systemd-user-service-dir, but personally I expect them to be installed under the same prefix.
Also, these services are not searched by default only in locations under /usr, they are at least also searched under /usr/local. And for any other prefix, you can tell D-Bus where to find the services by setting XDG_DATA_DIRS, and for systemd you can use systemctl --global link.
For comparison, Thunar and Tumbler honor the installation prefix for these two services. It would even be possible to honor it while using pkg-config, with something like :
My general thought about these sorts of things is "works by default". If someone sets a prefix outside /usr or /usr/local, I want it to work without them having to do anything extra. Sure, you can argue that people installing in non-standard prefixes should need to know about dbus/systemd search paths, but I'm not sure I'd agree with that. (The amount of "hidden knowledge" required to administer a Linux machine grows every year, and I'm not sure it's fair to expect everyone to keep up with everything.)
But I also would agree that it's annoying to have to specify more options (beyond just --prefix) in order to get things installed solely under one prefix.
The problem is that if I set the default to always honor --prefix, then there's no good, straightforward way to tell configure to do it the "works by default" way. I suppose --with-dbus-services-dir=default or =auto could be the way to do it, but to my knowledge I've never seen a configure script that works that way (often =autois the default).
Another thing I'm curious about: those pkg-config variables were provided for a reason, and what is that reason? Is it mainly so users themselves can do something like --with-dbus-services-dir=pkg-config --variable=session_bus_services_dir dbus-1`? Or is it actually intended for use in configure scripts (or other automated build tools)? My gut feeling would be the latter, but I don't know.
I understand, asking to use the --with-* options is a solution in this case. What I don't like about it is that a default install under /usr/local for example might overwrite files from a system install under /usr. But one can argue that having concurrent installs is not a good practice, or that if you do it you are supposed to be careful :)
Right, that's my concern, too. I generally think of /usr as "owned by the system package manager", and don't like installing things manually there myself.
There's also the matter of uninstall; sure, make uninstall works, if you still have the source tree around, and remember what you passed to configure when you installed it. But just being able to do rm -rf $prefix is nice, and I don't love breaking that.
But then I also think about my own use case: I install in /opt/xfce4-git, and every time I restart X, I have to go and kill a few things that have started out of /usr and start the ones in /opt/xfce4-git. I probably shouldn't optimize for my own use case, though.
So I'm not sure... you've certainly given me a bit to think about, and I may change it back, and put a note in the README about how to use pkg-config to find the right paths if necessary.