don't use d-bus activation

[rezso]

if I have mate and xfce, both mate-notification-daemon and xfce4-notifyd works, because both starts via d-bus.

based on
https://git.gnome.org/browse/notification-daemon/commit/?id=1ad20d22098bc7718614a8a87744a2c22d5438d0
https://git.gnome.org/browse/notification-daemon/commit/?id=e05ae7cdc663ce2ea635c11fe78e9c07d2e1c9af
https://git.gnome.org/browse/notification-daemon/commit/?id=219b0af927346c0f29f60c79881a847f5351a6e6
https://git.gnome.org/browse/notification-daemon/commit/?id=fee6ff0cf33ce5bd4c0ac0280cf9dfffcec4b94b

[rezso]

in addition, we need to remove the exit-on-idle thing...

[monsta]

How the behavior is changed after this (in both MATE and other desktop environments)?

[rezso]

If you apply both patch (https://github.com/rezso/mate-notification-daemon/commit/ee632d85217591611143088d94cf032e3079c016 and https://github.com/rezso/mate-notification-daemon/commit/9dd47e22f8e40afaa076662ec257810ba50ed0e7) it works as expected in mate session, but doesn't starts in other desktop environments.
(ps fax output under lumina: https://gist.github.com/rezso/c616fe0d7d91f8dbc389, and under xfce: https://gist.github.com/rezso/a6c80c1cc27af22b20bb)

[stefano-k]

Just to remind past discussions about this
#10

[rezso]

I don't saw the past discussion, but this means, that this is an old problem, so I think we need a proper solution to prevent conflicts between different daemons...

[cygwinports]

Yes, its an old problem which the specs haven't taken into account (until recently, e.g. the MIME Apps spec). #10 is the proper solution to this problem.

[raveit65]

In the past i saw some crashes of m-n-d which happend in other DEs at redhat bugzilla.
So for me this PR is valid.

[monsta]

I'm not sure that it's meant to fix any crashes...

[raveit65]

But it fix crashes if m-n-d starts in the wrong desktop enviroment

[raveit65]

In a VM with mate and gnome-flashback installed.

[rave@qemu-f22 ~]$ env | grep DESKTOP_SESSION
DESKTOP_SESSION=gnome-flashback-metacity
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
[rave@qemu-f22 ~]$
[rave@qemu-f22 ~]$ ps aux |grep notification
rave      1887  1.0  2.1 476968 21888 ?        Sl   10:19   0:00 /usr/libexec/mate-notification-daemon
rave      1891  0.0  0.2 114352  2220 pts/0    S+   10:20   0:00 grep --color=auto notification
[rave@qemu-f22 ~]$
[rave@qemu-f22 ~]$ rpm -qa notification-daemon
notification-daemon-3.16.1-1.fc22.x86_64

I'm really tired about that m-n-d starts in other desktops.
We have a solution to fix that.

PS: same happens in xfce session

[raveit65]

After testing this a bit i'm not shure anymore if this is progress.

• m-n-d crashed very often
• no restart after crash

[rezso]

Weird. Never crashed for me.

[monsta]

@NiceandGently: does it crash only after applying this PR?

[raveit65]

I mostly tested it with gtk3 on my main box, and a bit in gtk2 VM.
Maybe it was this fixed issue #69
Or with slider gtk3 version which is still buggy.
But this points out the real prob, without dbus activation we lost the daemon in session if it crashed for some reasons, and you need to restart session.
Which is bad, i know users who never restart the system or session.
So we need an autorestart for the daemon.
Second prob is if xfce or other notification-daemon don't change their behaviour you will always see their daemon in session.
This is currently the situation in gnome-flashback session, here always wins mate of xfce notification daemon.
Don't forget that there are a lot of notifications server which use dbus activation, see https://wiki.archlinux.org/index.php/Desktop_notifications

[monsta]

Yes, that's an interesting question - should we bother to change the behavior of our notification daemon when there are other ones which didn't do the same yet?

[monsta]

For reference:
https://bugzilla.xfce.org/show_bug.cgi?id=7950 - wontfix
https://bugs.debian.org/640082 - wontfix

No comments 😄

[raveit65]

Imo, a better solution is to go the way how gnome or kde implement their notifications to be independent from freedesktop notification-daemon.
Maybe re-activating libmatenotify is the solution.
But i can't really remember if this was a prob in the past with libmatenotify.

[monsta]

Well, libmatenotify is just an old fork of libnotify... what would it give us?

Anyway, even if we change it one way or another, there's still a question... Imagine that user installs some other notification daemon which is dbus-activated. Now which daemon will receive the command to display notification? 😄

[rezso]

@monsta : „https://bugzilla.xfce.org/show_bug.cgi?id=7950 - wontfix”
https://bugzilla.xfce.org/show_bug.cgi?id=7950#c4: „I don't see any advantage for Xfce users” is the best reason :p
Adding initd/systemd service file is a possible solution for restarting the crashed daemon?

[raveit65]

We can add m-n-d to required-components, same we did for docks with 1.11.
In result mate-session-manger can autorestart m-n-d.
But that will not happen before 1.13 dev phase.

[skoehler]

I have been suffering because of this for ages now. Skype locks up, cause no notification daemon is running. nm-applet (NetworkManager) locks up, cause there is no notification daemon running. Etc.

I finally found the cause, and I'm utterly disappointed that it hasn't been fixed yet. I cant even fix it manually by starting the mate-notification-daemon on login, cause it exits after some idle time. Ha ha, this must be some kind of joke.

Yes, I have two desktop environments installed (MATE and kde-plasma) but that shouldn't result in a pain in the butt. I'm mentioning that cause the kde-plasma's /usr/share/dbus-1/services/org.kde.plasma.Notifications.service apparently prevents mate-notification-daemon from auto-starting.

Remove the code for exit on idle, please. Or at least add some kind of command line option to disable it.
This bug has been ruining my Linux desktop for very long now. I blamed it on Skype or nm-applet, but instead it has been the broken notification-daemon the whole time.

[joakim-tjernlund]

I have been suffering because of this for ages now. Skype locks up, cause no notification daemon is running. nm-applet (NetworkManager) locks up, cause there is no notification daemon running. Etc.

I finally found the cause, and I'm utterly disappointed that it hasn't been fixed yet. I cant even fix it manually by starting the mate-notification-daemon on login, cause it exits after some idle time. Ha ha, this must be some kind of joke.

Yes, I have two desktop environments installed (MATE and kde-plasma) but that shouldn't result in a pain in the butt. I'm mentioning that cause the kde-plasma's /usr/share/dbus-1/services/org.kde.plasma.Notifications.service apparently prevents mate-notification-daemon from auto-starting.

Remove the code for exit on idle, please. Or at least add some kind of command line option to disable it.
This bug has been ruining my Linux desktop for very long now. I blamed it on Skype or nm-applet, but instead it has been the broken notification-daemon the whole time.

Me too, we have MATE, Plasma and Xmonad installed so our users can choose.
Until now I haven't noticed the problems described here but as of today(after updating the my box) I
see plenty of stalls, notify-send etc. not working. Don't know why the it suddenly got so unresponsive though.
I removed org.kde.plasma.Notifications.service and then it started to work.

[joakim-tjernlund]

Just got bitten by this again. Seems to be somewhat random which notify-impl is selected.
Now plasma is always auto selected and MATE does not work.

[jpalus]

Issue keeps on biting in 2021 as well... trying out wayland with sway and mako, going back to MATE and notification daemon does not work.