<div dir="ltr">David,<div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 31, 2015 at 2:10 AM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday 30 January 2015 16:34:51 Jeremy Whiting wrote:<br>
> Ok, I took a deep look inside kbuildsycoca5 today. I ran Instruments on it<br>
> and found as Marko already pointed out most of the time spent in there is<br>
> delving deep into /Applications subfolders. I'm not sure exactly what it's<br>
> looking for, mostly .desktop files from what I saw, but it's not finding<br>
> any.<br>
<br>
</span>Yes, .desktop files.<br>
<br>
Since you're patching Qt anyway for Macports (it seems), you should probably<br>
change ApplicationsLocation to remove /Applications and only keep<br>
/opt/local/share/applications in there.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Traversing the whole tree is time consuming though, and we know it's<br>
> not likely to find .desktop files inside any .app bundles, so I added the<br>
> attached patch and that sped up both kbuildsycoca5 itself (running from the<br>
> terminal manually)<br>
<br>
</span>Patch looks good, you can commit it.<br></blockquote><div><br></div><div>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? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Could you point me at some documentation or explain to me a bit what the<br>
> difference between kinit, kded, kbuildsycoca and klauncher is? I know<br>
> kbuildsycoca checks for system configurations and caches them, like<br>
> contents of .desktop files and such, but I'm not sure where the others fit<br>
> in or what they are for exactly.<br>
<br>
</span>kded watches the same dirs, so that it can launch kbuildsycoca when a .desktop<br>
file is installed/removed/changed.<br>
<br>
kinit and klauncher are mostly separate from that. kinit is the "fork+exec to<br>
avoid relocations" mechanism (see kinit/README.md), and klauncher is the DBus<br>
API for it (kinit can't initialize DBus, since that would be inherited after<br>
forking).<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Thanks for the information, I do appreciate it.</div><div>Jeremy </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
</font></span></blockquote></div><br></div></div>