On Thu, 13 Jan 2022 05:16:51 -0500, The Natural Philosopher <t...@invalid.invalid> wrote:
> However he did say 'start on login' which lets out most of te system
> approaches to starting code and suggest the autostart menu
Wrong.
$ systemctl --user status
●
x3.hodgins.homeip.net
State: running
Jobs: 0 queued
Failed: 0 units
Since: Tue 2022-01-11 18:02:15 EST; 1 day 13h ago
CGroup: /user.slice/user-500.slice/us...@500.service
├─redshift-gtk.service
│ ├─3535 /bin/bash /usr/local/bin/redshift-gtk
│ ├─3612 /usr/bin/python3 /usr/bin/redshift-gtk
│ └─3613 /usr/bin/redshift -v
├─pulseaudio.service
│ └─2835 /usr/bin/pulseaudio --daemonize=no --log-target=journal
├─gvfs-daemon.service
│ └─3618 /usr/libexec/gvfsd
├─init.scope
│ ├─2391 /usr/lib/systemd/systemd --user
│ └─2395 (sd-pam)
└─dbus.service
└─2865 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
$ tree -ifa .config/systemd/user/
.config/systemd/user
.config/systemd/user/default.target.wants
.config/systemd/user/default.target.wants/redshift-gtk.service -> /etc/xdg/systemd/user/redshift-gtk.service
.config/systemd/user/ethumb.service -> /dev/null
So as above, I'm using systemd user units to cause redshift-gtk to start and to
stop ethumb from running.
Also, see "man systemd-xdg-autostart-generator", and try opening a terminal
and running xdg-autostart.
Neither xdg or systemd user units involve a desktop environment's autostart, but
both start things on user login. There's also dbus that can run things on user
login.
On user login, the autostart menu is just one of several ways things can start on
user login. As I mentioned before, if multiple desktop environments are installed,
the non running desktop can still activate things from it's autostart on user login.
Without knowing which distro and package is involved, and what desktop environments
have been installed, so things can be looked at to see which methods are used, the
question cannot be answered.
Regards, Dave Hodgins