ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[Kevin Funk]

On Saturday 22 August 2015 11:34:38 David Faure wrote:
> On Wednesday 19 August 2015 09:08:35 Boudewijn Rempt wrote:
> > A windows or osx application for the masses must:
> > * not have any pre or post install procedures
> > * not start any process except the application itself
> > * avoid ipc as much as possible
> > * find all resources and plugins relative to itself
> > * be portable (moving it around should not be a problem)
> 
> OK, I understand.
> 
> I am currently fixing a first issue, ksycoca usage (e.g. KServiceTypeTrader)
> starting kded for watching files. It will instead compare timestamps
> itself. This also means, no post install procedure ever, because the app
> will be able to realize it needs to rebuild the cache (kbuildsycoca5) all
> by itself, reliably.
> 
> Hopefully it will also fix the bug you're seeing (which Milian experienced
> too, since), although I'm still a bit puzzled by what's happening there
> (one could try going back to one commit before ddd57bccdf, to check if it
> introduced the issue?).
> 
> Another thing that could be done about this BTW would be to port all
> PreviewJob plugins to JSon (and ensure they are all in the same plugins
> subdir) and use KPluginLoader to load them -> no trader query needed
> anymore. Is anyone interested in doing that?
> 
> Meanwhile I'm working on ksycoca because we need it anyway for application
> desktop files, even if all plugins move to json.
> 
> 
> A second step that could be done to avoid external processes would be to
> move the kbuildsycoca code into the kservice library itself, i.e. any app
> looking up something might first recreate the cache itself. That code
> already uses QSaveFile so two apps wouldn't be able to overwrite each
> other, but I suppose we still don't want 10 apps noticing at the same time
> that they need to rebuild the cache and doing it all in parallel. So I
> would use a QLockFile around that code. This of course increases the
> library size by merging another 3075 lines of codes into it, which is why
> it was never done before, but if this is wanted for Windows/OSX and nobody
> has a strong objection against this, I can do it.

Disclaimer: I'm streamlining KDevelop on Windows atm.

I'd also be interested in a solution that doesn't require me to have several 
processes running alongside of kdevelop.exe. As Boud indicated, this is indeed 
a no-go on Windows.
 
> This leaves a bigger issue though: KIO uses separate processes, the
> kioslaves. I'm not offering to change that right now. Is there really no
> way to make that work seemlessly on Windows? At least they don't pop up a
> black window like kbuildsycoca, right? :-)
> 
> You mention "daemons stick around after you quit the app". That is certainly
> true of kdeinit and kded, but kioslaves exit after being idle for 3
> minutes. You want KDE_FORK_SLAVES=1 for the one-app-on-Windows use case,
> btw. I *think* they even exit when the app closes, but that has to be
> checked and possibly fixed.

Right now whenever I start kdevelop I get the following daemons up and running 
on Windows:
- dbus-daemon
- kded5
- kglobalaccel5
- kioslave
- klauncher

For the one-app use-case: Which ones do I need? How to stop them from being 
started? (Sorry, but I never really looked into that matter either, so any 
help welcome here). Given that KIO slaves can be invoked via fork, none of 
them (besides dbus-daemon for IPC) should be required, no?

Didn't know about KDE_FORK_SLAVES yet, thanks!

> Anyhow - don't move away from KF5, let's work together :-)

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150824/2da7fbd8/attachment.sig>