I am testing 14.2 64-bit before updating several systems from 14.1 64-bit. In both OSs I have MATE and Xfce installed.

I almost always use MATE. In 14.2 notification popups trigger xfce4-notifyd rather than mate-notification-daemon. When I temporarily rename org.xfce.xfce4-notifyd.Notifications.service, then mate-notification-daemon is used as expected.

I cannot replicate this behavior in 14.1.

I have two systems with 14.2 installed for my testing. One is a desktop and the other a laptop. The laptop exhibits the problem, the desktop does not. Other than hardware, the only differences I am aware are using NetworkManager on the laptop and NVidia drivers on the desktop. Otherwise the two 14.2 systems are practically identical. I installed 14.2 fresh on both systems and methodically migrated /etc settings, etc. User homes are on a separate partition and are the same for both 14.1 or 14.2. I can dual boot into either 14.1 or 14.2 on both test systems.

The problem occurs regardless of user account, including root. Thus the problem seems to be system related rather than desktop or user.

In 14.1 I am using MATE 1.12. I am aware that parts of MATE 1.16 are compiled with GTK3. I do not know if that plays a role. I do not know whether something significant changed between 1.12 and 1.16 with respect to dbus, or similar with Xfce, or whether something similar changed between 14.1 and 14.2. MATE packages were downloaded and not compiled locally.

Using notify-send through strace revealed nothing. No clues in any logs.

Any insight about this anomaly is appreciated.

Both mate-notification-daemon and xfce4-notifyd are notification servers (as others listed in this page) and as such implement the server side of the Desktop Notifications Specification, which is desktop agnostic, I think.

My assumption is that, for a reason (unknown to me, sorry, so I don't have a real answer to your question) in one of the systems mate-notification-daemon runs first, in the other one that's xfce4-notifyd instead. Anyway I don't think that which one runs matters at all, as long as the notification are properly provided, e.g. you see the pop-up bubble "Hey! You got an email!". What would be really annoying is receive a notification twice, or not at all.

I wouldn't bother as long as it works. As they are redundant you could remove one of the notification servers to check if everything still works in both desktops just to feel safe.

PS The spec says (bold mine) "In order to ensure that multiple notifications can easily be displayed at once, and to provide a convenient implementation, all notifications are controlled by a single session-scoped service which exposes a D-BUS interface." So I assume that some mechanism (unknown to me) prevents to start a service if one is already started. Which is a good thing

PS for expert users like you not installing KDE is acceptable. But not installing bsd-games, hence not displaying a Fortune upon log in is forbidden by the Slackware Tradition

1 members found this post helpful.

Yes, functionally there is no difference. I am curious why Tron is going left rather than right..

I hoped strace would provide a clue but not so.

Perhaps one of the Slackware MATE devs might have an inkling.

Indeed -- my transgression is forever recorded on my permanent record.

An interesting tidbit. I copied my office desktop 14.2 partition to the laptop. Updated fstab, etc. The quirk remained on the laptop. Inconclusive, but seems the quirk is related to the laptop.

Entropy may be the culprit then

I have beeen known to blame cosmic rays for quirks. Although after many years of this I am not too stiff -- probably 95% of what happens is PEBKAC. In this particular case I am without clues to what I might have done to cause the differing behaviors. For my mental health I should let this go, but the deeper I go down the rabbit hole the more ingtrigued I become.

I wish I was a C wizard and could follow the rabbit trail with dbus and libnotify.

Hopefully eventually somebody who has seen something like this will notice the thread and offer a hand. Don't care that I might be the butt of the joke. Just want to know.

Rabbit hole? This remind me of manuscript that ended up at the British Library:
https://www.bl.uk/collection-items/a...-in-wonderland

http://www.bl.uk/onlinegallery/ttp/a...roduction.html

Sorry to be still off topic, I will try not to do that again.

One of my favorite stories. Carroll denied the stories were satire, but they are easily read that way. I am long overdue for reading them again.

I think "rabbit hole" is an apt description of this quirk.

Or not. I installed Salix Xfce 14.2 on another partition on the laptop and installed the MATE package group. The notifications behave and use the mate-notification-daemon and not xfce4-notifyd . I am sure that is a clue but Inspector Clouseau I am not.

Old thread but the thread is mine

With my recent excursion from MATE to Xfce, I noticed on starting Xfce the mate-notification-daemon running.

I narrowed the culprit to the Xfce Pulseaudio panel plugin. For some reason the applet calls the mate-notification-daemon rather than the xfce-notifyd. In about 30 seconds the mate-notification-daemon disappears. More or less the opposite observation in my original post.

To quote Alice, "Curiouser and curiouser."

Odd. I don't know enough about this specific situation but it sounds a bit like a race condition, possibly involving dbus.

I can't say for *sure* but I've a feeling I've come across this happening in KDE as well - ie the xfce notification daemon getting activated rather than the KDE one.

I'll look into this later but it does sound like a race condition to me.

Makes sense to me, but I'm not a programmer with any experience knowing how to debug or trace. Hardly the end of the world but if you find anything please post.

Wow, my research indicates that dbus basically has a pretty nasty bug/limitation, in that if two or more programs provide the same dbus service, dbus has no way of deciding to prefer one over the other based on what DE, you're running, and just arbitrarily picks one.

See: https://bugzilla.redhat.com/show_bug.cgi?id=484945

This bug has been open for 10 years.

What is recommended by RH developers (and others) is for NO ONE to own this service as a result, and to have daemons within the desktop use the FDO autostart standard instead, to accomplish notifications.

This is the way all major desktops, except XFCE, handle this.

See: https://bugzilla.xfce.org/show_bug.cgi?id=7950

EDIT: Not true. Both KDE5 (as of ~ 2017 if my research is correct) and MATE also implement their notification daemon in this manner, using dbus. Both have bug reports filed.

See: https://github.com/mate-desktop/mate...mon/issues/115 - MATE

https://bugs.kde.org/show_bug.cgi?id=381693 - KDE



A patch from RH was proffered by the Cygwin ports maintainer, urging XFCE to push it upstream, nuking their org.freedesktop.Notifications registration, and implementing this functionality through autostart instead.

See: https://bugzilla.xfce.org/attachment.cgi?id=6334

The XFCE devs rejected this patch, basically saying, this isn't our problem - dbus, fix your shit.

Fair enough, but as a result of dbus's brokenness, the issue still stands.

So to answer your question, it looks like you'll have to either live with this behaviour, or nuke org.xfce.xfce4-notifyd.Notifications.service while you're running MATE.

Another cute way of working around this may be to write a script similar to what KDE's "plasma_waitforname" program does, and test for whether XFCE is running, and if it is not, just exit silently - you could then modify org.xfce.xfce4-notifyd.Notifications.service accordingly.

EDIT: I doubt this would work, upon second thought. It may result in stopping a notification from appearing rather than using the notification daemon from another desktop erroneously, but given the issues dbus has in this regard, I doubt it would be "smart" enough to move to the next service detected owning this namespace if it received a nonzero exit status from the first one it detects and tries.

3 members found this post helpful.

Insightful Poprocks. Thank you!

And conversely neutralize mate-notification-daemon when Xfce runs.

Probably doable on a Slackware system by looking to see what xinitrc is sym linked or if the user has a local .xinitrc. I don't use a login manager so I have to look into that -- in the old days a local .dmrc file provided the clues.

As I am testing Xfce an alternate desktop for at work, where we don't use Slackware (using Ubuntu MATE), I'll have to dig deeper to see how to resolve the conflict. I already discovered one irritating bug for the work environment. When in Xfce the ssh-agent is not showing a GUI dialog prompt for private SSH key passphrases. I can live without that because the prompt occurs on the command line, but the ssh-agent is not retaining the passphrase for the session. Retyping every instance is a serious inconvenience.

1 members found this post helpful.

I edited my previous post because I realized some of the info was no longer accurate - and I woke up in a cold sweat realizing the proposed "cute" workaround I suggested would probably not work.

This is a pretty nasty issue in dbus IMO that I feel could possibly be exploited by someone thinking nefariously. I hope it is fixed soon. The response by the KDE dev in their respective bug report is basically, well, there is a proposed fix in dbus, and this area is rubbish anyway, so let's just leave it open to glitches if it conflicts with other desktops.

It also seems that KDE only started doing things this way 2017 - I don't know why they would introduce this as a potential pitfall when it has already been strongly advised NOT to implement notifications in this manner until dbus is fixed.

What a mess!

Unless all affected desktops are patched (ala what Red Hat does, by the look of it), manual intervention is necessary for individuals running multiple affected desktops.