Applet mode?

[bkw777]

Possible enhancement.
Re-impliment notify-loop.sh, notify-send.sh, and notify-action.sh all in vala in the app itself and get rid of the shell scripts.

This is just an idea. I have no idea if I can figure out how to actually do it, or if it's even a good idea. I just want to write it down somewhere for consideration and/or to serve as a back burner TODO/Wishlist item for reference.

The scripts are now working MUCH better than originally, but notify-loop.sh still has a problem that I just don't know if there is any proper fix for. The problem is it keeps running after the user logs out of their desktop session. I have it now killing it's predecessor each time a new instance starts up, so there is generally only one un-wanted instance running all the time, but it's still basically wrong for it to keep running after the session logs out.

Apparently reason it keeps running is that it's not actually started by the desktop environment. It's started by systemd-logind.

You CAN tell systemd to kill all the processes it started up by putting KillUserProcesses=true in /etc/systemd/logind.conf

That would kill it at log-out, but there are several problems with that:

• It's wong for any app to require the user to make that kind of system level config in order for the app to work. If your distribution doesn't already have that option set by default, or if you have intentionally set that option the way you want it, it's not some dinky little apps place to expect you to change that for it's convenience.

• That setting affects ALL forms of user login session, including ssh logins, and kills "screen" sessions or any other intentionally forked background task that you might have intentionally started. Systemd provides a special command that you can use to prevent it from killing a particular process, but I find that annoying and unreasonable. I already did all I should have to do to make a process live after ending it's parent process, just by using "screen" or tmux or nohup or setsid etc in the first place. Now I have to also do some arcane systemctl command that I will have to google up to remember what it is every damned time...
  So, I don't consider that an acceptable official answer for how to use mainline, and none of the other desktop session components need any such crap to close at the end of the session.

But the other desktop components that ARE started by the desktop environment itself, and so, killed by the desktop environment rather than by systemd, there seems to be no good standard for how those are defined or managed.

~/.conf/autostart/*.desktop works for any desktop, but if I wanted the LXQT equivalent of that, then it's an LXQT-specific config file that means nothing to any other desktop environment. Gnome has something else, KDE has something else... I don't really want to try to support a handfull of different desktops with their own custom methods, especially when I don't run them and am not testing them, and then also necessarily simply failing to support all other desktops.

So I'm thinking a possible answer is to keep using systemd to launch the process, but instead of the simple notify-loop.sh, have it start an executable that connects to dbus and/or an X display, and then that app could reliably close itself based on dbus messages and/or loss of X connection. That would be mainline or mainline-gtk itself with some kind of new applet mode, probably invoked by a "--applet" flag.

[stsdc]

Look at Monitor it runs in background (if You close a window), has option to run in autostart and also has an interface for DBus. Maybe it will help with solution.

[bkw777]

Thanks for the pointer. Assuming I can follow it, it's great that it has both autostart and dbus already, because that elimitates all 3 of the external shell scripts and makes 4 different things better.

• checking for kernels periodically in the background
• ending naturally along with everything else from a given desktop login session
• sending a notification
• responding to action buttons from a notification