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 m...@milianw.de http://milianw.de _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
