I'm using notification-daemon to handle desktop notifications, because
the libgtk fallback has a bug interacting with my window manager.

I find that it works fine for a bit, but after a while it stops
working.  When it's in the non-working state, some senders of
notifications seem to use a fallback in libgtk, but in this state,
notify-send(1) prints this

  GDBus.Error:org.freedesktop.Notifications.MaxNotificationsExceeded: Exceeded maximum number of notifications

I UTSL and it seems to have a queue of at the most 20, where things
get added if they're sent over dbus, and deleted if they're dismissed
by the user.  But nothing else removes them.

ISTM that if the user doesn't dismiss notifications they should
expire, or something.

Thanks,
Ian.

was presumably intentional (although I don't know the reasoning behind
it). It is unlikely to be fixed, because nobody is developing
notification-daemon any more (https://bugs.debian.org/1092972). Instead,
desktop environments use various other implementations of the same D-Bus
API that originated in notification-daemon.

It's part of the GNOME umbrella for historical reasons, but GNOME hasn't
used it for around 10-15 years at this point: the implementation of the
Notifications interface that is actually used in GNOME is part of
gnome-shell. Similarly, other major desktop environments usually have an
integrated implementation of Notifications, either built-in to some
larger component (like KDE Plasma Workspace or Cinnamon) or as a
separate service (like xfce4-notifyd).

If you are using an integrated desktop environment, I would recommend
using its implementation of Notifications. If you are assembling your
own desktop environment from smaller components, there are several
non-desktop-specific implementations available such as dunst and
notify-osd, or some of the separate services like xfce4-notifyd might
also work outside their intended desktop environment. I am not able to
recommend a specific implementation that would be most appropriate for
everyone.

I think we should remove notification-daemon during the forky cycle:
it's an excellent example of how "reference implementation" does not
always imply "high-quality implementation for general use".

     smcv

I wrote:>

dunst works great for me.  <3

I would still like to fix #1087207 as a service to other users.

Ian.

Hi.  Thanks for the useful info!

Simon McVittie writes ("Re: Bug#1107242: /usr/lib/notification-daemon/notification-daemon: stops working after a bit if user doesn't dismiss bubbles"):
n> such as dunst and notify-osd,

Thanks for the suggestions.  I will try them out.

xfce4-notifyd is afflicted by a bad interaction with my window
manager:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087207

I now think this is a bug in libnotify or libgtk, because nm-applet
seems to be doing the smae thing if I don't have a notification
service on my session dbus.

Oh.  Yes.

I find it difficult to imagine why someone would think this behaviour
appropriate.  There are no code comments about it.  I think the
authors just assumed that the user would always explicitly dismiss
notifications.

I agree that the code is quite simplistic and the behaviour can be
poor.  But from my POV it has the advantage, over the other
possibilities I have tried so far, that all of its bugs are
tolerable.  (#1087207 is intolerable in my setup.)

If I find that none of the alternatives work for me, I may consider
adopting this package (and therefore fixing the worst of its bugs).

If you have suggestions for a lower-level tool that could be used as
part of a replacement implementation, that would also be very
interesting to me.  A CLI utility that emits a stream of jsonlines, or
similar.  My natural inclination leans about as much towards
"reimplement in Tcl" as it does to "declare myself de facto upstream
for an ancient abandoned C program".

I already tried a bit of "debug a desktop library's X11 wm hints
handling" without success so far.  If you have any advice for me in
#1087207 that would be greatly appreciated.  Otherwise I guess I will
blunder on as best I can...

Thanks,
Ian.