ksycoca improvements (Re: assert in kservicetypefactory.cpp)

[David Faure]

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.


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.

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

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