kiconloader's other api change

[David Faure]

The other API change that happened in kiconloader while I was on vacation,
is that KGlobal::iconLoader() is now kapp->iconLoader(). While this might look ok
since most kde code is using kapplication, I don't like it, it's going in the wrong direction,
after all the kapp-> dependency cleanup that happened in kdelibs trunk.
For instance, it breaks when unit testing the code, since we made QTEST_KDEMAIN
*not* instanciate a KApplication on purpose, to catch kapp-dependencies.
In kde4, KApplication is a convenient initializer of things, but should be in no way required,
this is just too much trouble (reminder: kde widgets in qt designer, kde integration in non-kde apps, etc.)

I suggest that kapp->iconLoader() is removed again, and a static method KIconLoader::global() is
added to replace it.

static KIconLoader* s_global;
static KStaticDeleter<KIconLoader> s_globalSd;
KIconLoader* KIconLoader::global()
{
    if (!s_global)
        s_globalSd.setObject( s_global, new KIconLoader( KGlobal::instance() ) );
    return s_global;
}

Singleton-like, but not the only way to create an iconloader of course; only the global
one is handled like a singleton. Just like kdirwatch.

KIconLoader::self() might look too much like a real singleton, this is why I'm suggesting global() instead.
KGlobal::iconLoader() becomes KIconLoader::global(), it's somewhat logical ;)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).