Preface:
======
You've probably noticed the epic struggle we've had with Amarok 2
hanging on exit. After _months_ of tinkering I've now been able to
identify and fix this issue. This document explains how to prevent
such issues in the future.

What is a static object?
=================
A static object is being initialized on program start, and will only
become instantiated once. It's conveniently used with the singleton
design pattern, e.g. in Amarok code.

Example:

static AmarokMenu s_menu;

What is so dangerous about static objects?
================================
A static object's destructor is called _after_ the QApplication
destructor has been executed. This is fine for plain old datatypes
(POD) like int, float, and pointers, as they do not have a destructor.
It's also fine for objects with a trivial destructor that does not
interfere with the rest of the program.

The danger lies in using static objects that call other parts of the
application in their destructor. This is e.g. true for most QObjects,
which rely on the QApplication being intact. If the QApplication is
destroyed before the static QObject's destructor is run, _bad_ things
can happen. To name a few: Crashing, hanging, eating live kitten, or
forcing you to use XMMS.

How can I prevent these problems?
==========================
Use K_GLOBAL_STATIC, and use qAddPostRoutine() to ensure that the
static object's destructor is called when QCoreApplication destructs.

Example:

class AmarokMenu : public QMenu
{
  AmarokMenu();
};
K_GLOBAL_STATIC( AmarokMenu, s_menu )

AmarokMenu::AmarokMenu()
{
  // K_GLOBAL_STATIC is cleaned up *after* Q(Core)Application is gone
  // but we have to cleanup before -> use qAddPostRoutine
  qAddPostRoutine( s_menu.destroy );
}

Further reading:
===========
http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/group__KDEMacros.html


Thanks for reading, and happy hacking :)