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 | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
