On September 7, 2015 12:03:59 AM you wrote: > 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 was thinking for things like the K menu, having a significant pause when opening the menu would be a bad UX. And having each app implement its own caching layer would make things worse.
Also, since most people don't use make install to install/update programs, could we potentially miss something if we only watch the folder's mtime? > > 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). I agree completely. And as long as we can bring back the option without too much extra work, I'm not worried. I don't want to bikeshed this point, so whatever way you decide is fine by me. -- Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
