ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[Milian Wolff]

On Monday, August 24, 2015 1:03:22 AM CEST 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?

FTR: dbus  is required in KDevelop currently to enable it's "special" unique-
app-instance-per-session feature. [QK]LockFile was too unreliable on linux, 
DBus is trivial and magically works. It could be removed for Windows if it's a 
big issue and we find a good alternative.

Bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de