Wandering Thoughts archives

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 OnlyShowIn or NotShowIn 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 directory.

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'.

(GNOME .desktop files can also have a phase of GNOME's startup that they happen in; see here and here. KDE .desktop files apparently have somewhat similar properties too.)

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 for OnlyShowIn and 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, although xinput says that there is an overall 'Core Pointer' device.

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.)