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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
