ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[David Faure]

On Monday 24 August 2015 01:03:22 Kevin Funk wrote:
> 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?

Right, we can work on reducing that to dbus + kioslave.

You can help by reviewing https://git.reviewboard.kde.org/r/124876/
and testing it (on Linux and/or Windows).

It should fix kded being started, and possibly this was the cause
for kglobalaccel too.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5