I think it depends on what we are trying to achieve. From the title ‘How to autostart a snap of a desktop application’ I’m going to assume we are simply talking about getting something started and not ‘session services’ or ‘dbus activation of session services’. Leaving session services out of this…
For /etc/xdg/autostart vs ~/.config/autostart, I think it depends. In the deb/rpm world, /etc/xdg/autostart is of course owned by root:root, so the only way applications develeopers could put things there is via packaging install scripts. Some applications are written to have more control and instead they do not ship anything in the deb/rpm for /etc/xdg/autostart and instead on launch by the user, drop something in ~/.config/autostart. I think we would need to allow for both tbh, to accommodate existing software. Unfortunately, while ‘xdg-autostart’ appears to be a thing, it isn’t something that most software uses (ie, it isn’t installed by default).
I think we’d need to work through the design of the feature for how to handle it. For example, it is clear that we would want to generate the desktop files like we do in /var/lib/snapd/desktop/applications.
Less clear is if we want to support something like meta/snap/gui-autostart/foo.desktop (or similar) and just put the file in /etc/xdg/autostart unconditionally, controlled via an interface (and whether that is manual or auto-connected) or controlled via a new ‘snap autostart’ command like we do with aliases (that might have snap declaration support).
Even less clear is how to support ~/.config/autostart since xdg-autostart isn’t readily available and applications like Dropbox will just write to there (and most of the time they would be written to ~/snap/name/version/.config/autostart which is of course allowed, but not picked up by the session). From an isolation POV, we could allow writes to REALHOME/.config/autostart/snap_name_*.desktop (likely controlled via an interface). I can say that both of these worked in 16.04 LTS with Unity (ie, whether symlink or copy,
ln -s /var/lib/snapd/desktop/applications/gnome-clocks_gnome-clocks.desktop ~/.config/autostart/snap_gnome-clocks_gnome-clocks.desktop
cp /var/lib/snapd/desktop/applications/gnome-clocks_gnome-clocks.desktop ~/.config/autostart/snap_gnome-clocks_gnome-clocks.desktop
Someone from the desktop team would likely need to verify that a differently-named desktop file like this works in other desktop environments.
While writing this I had another idea-- perhaps the snap ships an autostart desktop file (eg, meta/snap/gui-autostart/foo.desktop) and on install snapd puts it in /var/lib/snapd/desktop/autostart/foo_foo.desktop. Then on userd start it looks in /var/lib/snapd/desktop/autostart for missing desktop files, checks if ~/.config/autostart/snap_foo_foo.desktop exists and if not, prompts the user if it should create it (remembering when the user says no). The user can later change her mind via 'snap autostart foo`. This would remove the need for /etc/xdg/autostart or any requirement for direct access to the autostart directories.