On Sunday 06 September 2015 17:59:13 Matthew Dawson wrote: > On September 6, 2015 01:52:37 PM David Faure wrote: > > 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: > Everything looks good from me, just one comment: > > > > > 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)... > > Instead of killing the kded component completely, could we instead make it > optional? That way in a full KDE session, we monitor the directories as > needed so we don't loose the file watching. Then if an application using > KService is launched outside the session, it falls back to this behaviour. > > Though the problem from point 4 still exists. Maybe make the signal be > specific to the cache? Since that would be more work then just a straight > port that no one has time to write, I wouldn't care if the kded component is > killed off currently, as long as it isn't a problem to bring back in a future > version where it would be useful.
I'm missing one point in your reasoning: what would we gain from keeping the kded code that watches desktop files and runs kbuildsycoca, if the apps do the same anyway, any time they need the sycoca contents? I guess this is an answer to my thoughts about the possible issue with nobody noticing a change for a long time, but I'm not sure the problem really exists. Hmm. Best way to find out is to look at all users of the databaseChanged signal, I guess. I'll do that then. I'd like to avoid solutions with "options" because it's more maintainance and more chances that the non-full-desktop case breaks (due to being less tested by most of us). -- 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
