How applications autostart on modern Linux desktops
A while back I mentioned that part of Microsoft Teams' misbehavior was autostarting when you logged in; recently, because I was testing some things on my laptop with alternate desktops, that behavior led to me uninstalling Teams. So all in all, it seemed like a good time to read up on how applications get automatically started when you log in (if they do) on modern Linux desktops like Gnome and Cinnamon.
(This is not normally an issue for me in my desktop environment, because everything in it is explicitly started by hand in a shell script.)
Unsurprisingly, there's a freedesktop.org
standard on this, the Desktop Application Autostart Specification,
which builds on the
.desktop file specification.
The simple version is that you set applications to autostart by
installing an appropriate .desktop file for them into either
/etc/xdg/autostart (for a system-wide autostart on login) or
~/.config/autostart (for an autostart for an individual user).
There are a number of special settings keys that can be in these
.desktop files. First, you can have a
key that controls which desktops should autostart this or not
autostart it (the specification misspells these keys in some mentions
of them). Second, you can have a
Hidden=true key, in which case
the application should not autostart (in any desktop). For obvious
reasons, the latter key is most useful in your personal autostart
Some desktops have custom keys of their own, and even custom locations for additional .desktop files to autostart; for example KDE before KDE 5 apparently also used ~/.kde/Autostart (see here). An important and common property is X-GNOME-Autostart-enabled, which is (still) in wide use despite apparently being deprecated. In particular, Cinnamon appears to implement disabling of standard autostart things by copying their .desktop file to your ~/.config/autostart directory and adding a line to the end with 'X-GNOME-Autostart-enabled=false'.
Some desktops have their own custom locations for various special things, or have had in the past (eg, also, and for LXDE). However, desktops don't necessarily use custom locations and settings. I know that with Cinnamon, if you add a new thing to be done on startup, Cinnamon puts a new .desktop file in your ~/.config/autostart.
More minimal 'desktops' may or may not automatically support .desktop autostarts. However, according to the Arch wiki's page on XDG Autostart, there are standalone programs that will do this for you if you want them to. On my normal machines, my own window manager environment is so divergent that I don't think autostarting .desktop files is of any use to me, so I'm not planning to try any of them.
(My work laptop runs a more or less
standard Cinnamon environment, which automatically handles autostarting
things. I believe that Cinnamon considers itself a form of GNOME
NotShowIn and so on .desktop keys. Cinnamon
certainly disables autostarted things using a GNOME specific key.)
Applications can arrange to autostart in at least two ways, the
honest way and the sneaky way. The honest way is to put a copy of
their .desktop file into
/etc/xdg/autostart. The sneaky way is
to wait until you run them once, then copy their .desktop file into
your ~/.config/autostart directory (re-copying this file every time
they're run is optional). Based on poking through the RPM package
for Microsoft Teams (and also how they apparently have a preferences
setting about this), Teams
appears to do this the sneaky way.
A scrolling puzzle involving GTK+, XInput, and alternate desktops (on Fedora)
Recently I discovered that cawbird wasn't recognizing certain 'scroll up' events in parts of its interface. This wasn't a new issue, although I originally thought it was; instead for years I'd been missing some of cawbird's functionality without noticing (and before it, corebird). I don't know exactly what the core problem is, but part of it appears to be some sort of interaction between desktop environments (or the lack of them) and the new approach to handling input devices using the X Input Extension.
The actual Cawbird issue is somewhat complicated and tangled, but fortunately it can be boiled down to a simpler situation through a test program that prints GTK mouse scroll event information (a copy of my version is here). For background, when vertical scrolling happens in GDK, you can see either or both of specific smooth scrolling events, with a Y delta of some value, and 'scroll up' and 'scroll down' events, which appear to always have a Y delta of 0.
On my desktop running fvwm outside of a desktop environment like Gnome,
what I see from the test program when I use my mouse scroll wheel
is just a stream of scroll up and scroll down events from a source
device of 'Core Pointer'. On my work laptop
running Cinnamon, scrolling on the touchpad generates smooth scrolling
events with various Y deltas depending on how fast I'm moving my
fingers, while using the scroll wheel on an external mouse generates
both a smooth scrolling event (with a Y delta of -1 or +1 depending
on the direction) and a 'scroll up' (or 'scroll down') event; these
events have a source device of either the touchpad or the USB mouse,
xinput says that there is an overall 'Core Pointer'
As far as I can tell,
xinput and the X servers are reporting that
the mice involved are set up the same way; the physical mouse (and
the touchpad) are extended input devices handled by XINPUT. But
something about my fvwm environment or how I start X on my desktop
is causing these GTK smooth scroll events to not be generated, to
the confusion of at least some programs (and there will probably
be more in the future). Unfortunately I have no ideas about what
it might be or how to track it down.
(After some further testing, I can say that OpenBox on my laptop and Cinnamon inside a VMWare virtual machine both cause GTK to generate smooth scroll events. The VMWare virtual machine is using my desktop's mouse, but the xinput mouse configuration is different because of VMWware stuff.)