ksycoca and kbuildsycoca, the next step

[Matthew Dawson]

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.
-- 
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3885 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150906/74a4fced/attachment-0001.bin>