autostarting apps in kde4

the what

as an application developer, you'd like your program to start up automatically when the user logs into their desktop. usually this is because your program is a desktop service type of application that should run from the time the user starts using the computer until they are done, such as a clipboard manager, password caching system or calendar notification daemon.

the way of accomplishing this has been standardized on freedesktop.org for open source desktop environments running on various unix flavours, but it has been generally left up to application developers to each follow that standard on their own. moreover, it really doesn't do much to answer the portability question.

in kde4 there is a new class that addresses this issue: KAutostart

the how

using KAutostart is intentionally pretty simple. for instance, if your application is already registered with the autostart system on the platform, to make your application start up at login one would simply write:


KAutostart autostart("myapp");
autostart.setAutostarts(true);


this assumes your application is set up for autostart already, however. on unix that would mean installing a .desktop file to $PREFIX/share/autostart/. but if you want to be rid of all of the details of dealing with .desktop files directly and would like to ensure future portability, you could do something a bit more thorough, like:


KAutostart autostart("myapp");

if (!KAutostart::isServiceRegistered("myapp")
{
const KAboutData* aboutData = KGlobal::instance()->aboutData();
autostart.setName(aboutData->programName());
autostart.setExec(aboutData->appName());
}

autostart.setAutostarts(true);


to check if your application will autostart the next time the user logs in do this:


KAutostart autostart("myapp");
bool willAutostart = autostart.autostarts();


KAutostart also reveals further features, some of which are KDE-specific, in the autostart process such as start phases, executables to check for as an autostart condition, which environments to start the application in or not and more. see the API documentation for complete coverage of all the bells and whistles.

the why

up until now, if an app wanted to engage in the wonders of autostart they'd just provide a .desktop file that looked something like this:

[Desktop Entry]
Encoding=UTF-8
Exec=huzzaboo
Name=Huzzaboo!
Type=Application

and throw it in $PREFIX/share/autostart during application installation ...

well, this produced several problems that have cropped up as the open source desktop has matured. first, there is the issue of multiple desktops. if everyone installs their autostart entries into, say, /usr/share/autostart then you can only imagine the lovely mish mash of kde, gnome, $RANDOM apps that start up, often innapropriately.

we do have OnlyShowIn= and NotShowIn= so if something is kde-only (e.g. the kde panel application: kicker) you can restrict it that way.

but what about apps that might want to be run on any desktop? (that would cover most apps, actually). usually we only want this to happen if the user starts that application up explicitly or if it's the "home" environment for it. today we recommend either using OnlyShowIn or NotShowIn or shipping with Hidden=true in the .desktop file and changing that to Hidden=false when the app is first run by the user (or configured to autostart). not exactly pretty.

and what happens when we change how autostart works (such as introducing a setuid binary that is responsible for handling new autostart requests for security purposes), or the app is ported to a platform that handles autostart completely differently? how will kiosk integration be handled?

the KAutostart class is intended to address these issues. by using it in your application you can avoid having to provide a .desktop file at all if you wish, which will help ensure portability or future proofing. as the autostart mechanisms evolved within kde, so will your application's use of it.

the disclaimer

KAutostart is a new class. the API will certainly evolve on its way to being an official part of kde4, so the contents of this article will probably change as well. i'll keep it up to date and eventually publish an official article on it.

(p.s.: yes, i'm abusing my blog as a way to start writing documentation about the bloody thing. blogging i've come to grips with. i'm still working on documentation writing. so sue me.)