kiconloader's other api change

[David Faure]

On Monday 08 January 2007 18:27, Thiago Macieira wrote:
> David Faure wrote:
> >I like how it makes the code shorter though. I just hope it works fine
> > in all the cases that kstaticdeleter was tested with (library
> > unloading; detecting calls after deletion - kstaticdeleter resets the
> > global pointer to 0 in its destructor). Time will tell.
> 
> QGlobalStatic (the hidden class behind Q_GLOBAL_STATIC) deletes the object 
> when the library unloads and sets the pointer to 0. Of course, since it's 
> static, it's rather pointless, because the library is being deleted -- 
> it's just for the cases where the function gets accessed after deletion.
Yes, exactly.

> In those cases, the caller must be able to detect a 0 pointer. I am sure 
> 99% of the code don't do that.
No, but for the 1% which checks it, it's useful. And compatible with kstaticdeleter, so that part is fine.

The trouble, as Matthias Kretz discovered, is that when quitting the app,
q_global_static objects are deleted after QCoreApplication is deleted.
This breaks when destructor code needs qapp, or qtimer, etc.

~KApplication destroys all kstaticdeleters, so in kde3 we made sure that it was done before there is no app anymore.
This is still true in kde4, but kapplication isn't used as everywhere as in kde3, so when using either kstaticdeleter
or Q_GLOBAL_STATIC, the destructor code runs after the application was destroyed. We can try
to stay away from "intelligent" destructors, of course, but let's hope that's enough.
Otherwise Matthias had the idea of using qAddPostRoutine to trigger that "iterate through global objects
and delete them" code before ~QApplication runs.

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