As a followup to recent discussions, I'm now looking into moving the recreating kbuildsycoca directly into the kservice library.
The rebuild now happens on demand when using any KService API and one the dirs with desktop files is more recent than the sycoca cache (that part is already in), so the next steps are: 1) kded no longer needs to watch the dirs with desktop files. I assume even the K menu doesn't just keep a cache of everything in memory, and use the KService/KServiceGroup API every time it's opened, so it should get the new stuff. However on demand means the old DBus signal databaseChanged() is either killed or at rebuild time by the app doing the rebuild (which could be later than when using file watching; possibly a very long time if no app calls into KService for a long time)... 2) kbuildsycoca5 will be kept as a way to force it to happen, but in theory it will be only needed when someone edits a .desktop file by hand (I checked, and "make install" touches the mtime even if an older version of the .desktop file was there, so that's fine). 3) Killing the mostly unused --checkstamps and --checkfiles options for kbuildsycoca. Its job of the app to trigger a rebuild, no point in having options for "no rebuild needed after all" in kbuildsycoca. I don't think anyone used these anyway. 4) I have one problem though. There is the case where the existing sycoca file, which was built for a given language, and a given set of XDG_DATA_DIRS, doesn't match the language and dataDirs of the running application. kbuildsycoca had code to detect that and discard the existing sycoca in that case (basically assuming --noincremental then). But if this logic moves to the apps (which would solve the long-standing issue of "kded is watching different dirs than what I set in my shell so the sycoca doesn't have what I need"), we have a possible bad scenario where two apps are running with a different language or dataDirs, then every time they look at sycoca they will think "there is a mismatch, I need to rebuild it". And every 5 seconds these two apps would rebuild sycoca to their liking, playing ping pong with it. In the freedesktop discussions around caches (shared-mime-info and the still-vapourware desktop file index) the idea was to have one cache per directory rather than one local cache which merges everything, which gets rid of the "different dataDirs" issue, and to have all languages in the cache, so no need to rebuild when changing language. But that's a much bigger redesign step for ksycoca which I'd like to avoid (one step at a time...). Any idea on how to avoid cache-rebuild ping pong? I can only think of one cache per (lang, dirs) combination somehow, but that seems tricky (a config file to point to some randomly generated filename for each combination?). That's quite some code for a case that rarely happens (but well, not handling this case was exactly the reason for the 15-years-old issue of "I export KDEDIRS from a konsole to add the install prefix of one app with plugins, and the app doesn't find its plugins because the session-started kded (which runs kbuildsycoca) doesn't know about that dir". Any feedback on the rest of the plans concerning ksycoca? -- 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
