[KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends

[Ian Wadham]

On 01/02/2015, at 1:28 PM, Jeremy Whiting wrote:

> David,
> 
> On Sat, Jan 31, 2015 at 2:10 AM, David Faure <faure at kde.org> wrote:
> On Friday 30 January 2015 16:34:51 Jeremy Whiting wrote:
> > Ok, I took a deep look inside kbuildsycoca5 today. I ran Instruments on it
> > and found as Marko already pointed out most of the time spent in there is
> > delving deep into /Applications subfolders. I'm not sure exactly what it's
> > looking for, mostly .desktop files from what I saw, but it's not finding
> > any.
> 
> Yes, .desktop files.
> 
> Since you're patching Qt anyway for Macports (it seems), you should probably
> change ApplicationsLocation to remove /Applications and only keep
> /opt/local/share/applications in there.
> 
> Yeah, that would work. I'd rather not have it remove /Applications, but it could certainly add /opt/local/share/applications to it's list of ApplicationsLocation locations. I'm a bit conflicted on the QSP issue currently. I can see as Rene pointed out it may be good to give all unixy paths when configured with a different flag at build time, but what if I created an application that used some kde frameworks but wanted it to give me OSX type paths for some things?
>  
> 
> > Traversing the whole tree is time consuming though, and we know it's
> > not likely to find .desktop files inside any .app bundles, so I added the
> > attached patch and that sped up both kbuildsycoca5 itself (running from the
> > terminal manually)
> 
> Patch looks good, you can commit it.
> 
> Ok, I will, I'll give it more thought, but I wonder which parts of kded/kbuildsycoca make sense on non plasma platforms. Another question that might help clarify this, do Gnome/Unity, other linux desktop environments use the cache kbuildsycoca creates when building their menus or is it strictly used by plasma (or rather kickoff/kicker which is part of plasma) itself? 
> 
> > Could you point me at some documentation or explain to me a bit what the
> > difference between kinit, kded, kbuildsycoca and klauncher is? I know
> > kbuildsycoca checks for system configurations and caches them, like
> > contents of .desktop files and such, but I'm not sure where the others fit
> > in or what they are for exactly.
> 
> kded watches the same dirs, so that it can launch kbuildsycoca when a .desktop
> file is installed/removed/changed.
> 
> kinit and klauncher are mostly separate from that. kinit is the "fork+exec to
> avoid relocations" mechanism (see kinit/README.md), and klauncher is the DBus
> API for it (kinit can't initialize DBus, since that would be inherited after
> forking).

Jeremy, kdeinit also has a man page and so does kded.  The kded5 one gives you an
overview.  The kdeinit5 one has some runtime options as well as a summary of what
is in kinit/README.md

> Ok, that does help explain what they are. Next is to know what uses them. Are they required for kparts to work, or for KService/KServiceTypeTrader to work? or is only kded required for those to function properly?

I think neither kdeinit5 nor kded5 is needed for KIO to work, but klauncher5 *is*.

If I start klauncher4 manually and deliberately crash an app on KDE 4, using
Apple OS X, Dr Konqi runs properly, including using KIO to communicate with
bugs.kde.org.  If klauncher4 is not running, Dr K fails as soon as it tries to send
anything to BKO, using KIO as a background process..

As far as I can remember, this used not to happen a few months ago (on KDE 4.13?).
I am now using latest KDE 4.14.  I seem to remember that klauncher used to be started
automatically from kdelibs4 and then KIO would run.

Today, if klauncher4 is not already running (on KDE 4.14 on Apple OS X), this happens…

drkonqi(25706)/kdecore (kdelibs) *KToolInvocation::klauncher: klauncher not running... launching kdeinit
drkonqi(25706)/kdecore (kdelibs) *KToolInvocation::klauncher: klauncher not running... launching kdeinit
drkonqi(25706): couldn't create slave: "Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files" 
drkonqi(25706)/kio (KIOJob) KIO::TransferJob::slotFinished: KUrl("https://bugs.kde.org/xmlrpc.cgi")
drkonqi(25706)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: KIO::TransferJob(0x7fd5a555a5e0) QObject(0x0)
drkonqi(25706) BugzillaManager::callFault: QVariant(QString, "login") 103 "Could not start process Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files."

Then all you can do is Cancel the dialog with Dr Konqi.

The messages suggest that klauncher cannot be started because there is something
wrong with the *.service files.  Didn't you have something to say about *them* being
wrong before, Jeremy?  What if you manually fix the relevant *.service file to be correct?
Will KToolInvocation then start up the klauncher-kio chain of processes correctly?

> Thanks for the information, I do appreciate it.

So do I, David.

Cheers, Ian W.