<div dir="ltr">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. 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) as well as makes kded5 responsive from what I can tell. I also ran kmahjongg and was able to save a game, though I got a warning about being unable to launch klauncher. I believe that's because it's .service file that dbus uses to launch it is not pointing at the executable. I'll look into that issue tomorrow.<div><br></div><div>Anyway, if you want to test this patch I'll post it on reviewboard once someone else has confirmed it improves kbuildsycoca5 slowness. This brings us one step closer imo.</div><div><br></div><div>David,</div><div><br></div><div>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.</div><div><br></div><div>thanks,</div><div>Jeremy</div><div><br></div><div>P.S. uncommenting the qDebug in there is just for testing, when I push this to reviewboard I'll remove that change.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 3:20 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Friday January 30 2015 17:21:25 Ian Wadham wrote:<br>
<br>
Morning<br>
<span class=""><br>
>I should have mentioned, "agent" apps cannot appear in the Force Quit… window,<br>
>i.e. the user cannot forcibly terminate them via the desktop GUI --- handy for kded<br>
>and kdeinit maybe --- but we should be careful how we use the "agent" option.<br>
<br>
</span>No, we have to test things well enough, but in principle (and my personal practice) agent applications are stable and simple enough not to require killing that way.<br>
<span class=""><br>
>@René: A thought for the future (KF5): I wonder if it would be good to install<br>
>"background" or "agent" apps somewhere away from /Applications, as with<br>
>Dr Konqi and others I noticed before.  Then they would not be visible at all<br>
>to end-users (normally), so no chance to start them accidentally.<br>
<br>
</span>It would be great if we could do something about the dump-style installation practices that put everything in the same directory, but that is probably not going to be easy and will have to come after everything is stable. On Linux itself there are only a very limited few (2?) places where executables go. This can be understood for what Apple calls "command line utilities" (or BSD utilities), but even on Linux there are now other ways to find an installed application.<br>
<span class=""><br>
>> on linux kded is installed into $PREFIX/bin so /usr/local/bin on my linux system. On OS X it went into /Applications/KDE/ but I'm not sure if it should be in /usr/local/bin or left where it is in /Applications/KDE/<br>
><br>
>Errmmm… that would be /opt/local/bin…<br>
<br>
</span>Or even ${prefix}/bin . Anyway, kded4 is in the same situation, as I think someone mentioned. And its .service and/or .desktop file(s) are not updated to reflect that fact. I seem to recall that other such files are, but I'm no longer sure about that. In any case akonadi finds its service apps perfectly, and IIRC those are at least in part installed as app bundles too (my Mac is still suspended so cannot check).<br>
<br>
Jeremy: if you haven't already, I'd strongly suggest you install a number of KDE4 applications through MacPorts, preferably using my "concurrent" Qt4 port and the various patches I uploaded (I could even send you my local port tree). That will give you a better idea of how the KDE/OS X marriage works currently.<br>
<span class=""><br>
>> Also can dbus services launch executables on OS X that are .app files ?<br>
><br>
>I don't see why not, if it provides the full sub-path (Contents/MacOS/<executable_name>).<br>
<br>
</span>And it can/does. Before I rewrote the OS X Keychain backend for KWallet, the standard wallet functions were used, and that worked fine. Kwalletd and kwalletmanager were started (2 more icons in the Dock because no one had made them agents yet), and as Ian noticed, wallet unlock request were systematically posted behind (all) other applications.<br>
<br>
Just one more thing: an application doesn't have to be in an app bundle in order to "attach" to the OS X window manager. That was never completely true, and it's more now. Of course that makes it harder to launch them properly, in the foreground (you'd need to go through LaunchServices), but that is of no importance for agent applications. kglobalaccel is a good example of this (which can also tell you what cmake commands lead to a non-app bundle executable).<br>
<div class="HOEnZb"><div class="h5"><br>
R.<br>
_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a></div></div></blockquote></div><br></div>