Running kded modules on non-KDE desktops

[David Faure]

On Sunday 10 January 2010, Thiago Macieira wrote:
> Em Sábado 9. Janeiro 2010, às 22.47.45, David Jarvie escreveu:
> > Applications which use time zone data get the data by calling
> > 
> >  KSystemTimeZones::local(), which in turn gets the system time zone from
> >  the kded module ktimezoned. This mechanism avoids the system time zone
> >  being read separately by each application - reading it can be time
> >  consuming, so fetching it once only is desirable.
> > 
> > This works in the KDE desktop, but when a KDE application is run under
> > 
> >  another desktop environment, ktimezoned isn't running and therefore the
> >  system time zone returned by kdelibs is always the default, UTC. Is
> >  there any way for ktimezoned to be activated automatically by kdelibs
> >  when it is required? If not, it is probably necessary for
> >  KSystemTimeZones to read the system time zone itself when it is not
> >  available from ktimezoned.
> 
> I thought kdelibs started kdeinit4, klauncher and kded when necessary.

Yes, so the fix is to define "KSystemTimeZones" as another place where
starting these daemons is necessary.

Otherwise, if the program didn't use ksycoca yet, the autostart didn't happen yet.
My suggestion: add this to KSystemTimeZones::local() :

if (QDBusConnection::sessionBus().interface()->isServiceRegistered("org.kde.kded"))
    KToolInvocation::klauncher(); // this starts kdeinit and blocks until klauncher is running

Hmm, technically that means kded might not be running yet, when
it returns, but one could add a small waiting loop (with a timeout in
case is crashed or something).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).