revisiting the sycoca
David Faure
faure at kde.org
Sat Feb 17 11:26:40 GMT 2024
[sorry for breaking the thread, copy/pasting from the archives after re-
subscribing]
On Tue, Feb 13, 2024 at 1:13 PM Sune Vuorela <nospam at vuorela.dk> wrote:
> At some point I remember David Faure, iirc as part of his QMimeType
> work, removed part of sycoca, but left the remaining bits as a per
> user cache *because* we allow the user to modify things.
Not exactly (or maybe I misunderstand).
ksycoca is a .desktop cache, and what changed in 5.0 was that mimetypes are no
longer defined by desktop files so indeed they are not in ksycoca anymore.
And the KParts are now using the Qt plugin JSON stuff so they don't use desktop
files anymore (right?).
But the main part still is in ksycoca: all the application desktop files.
And I don't believe this should change; here's why.
One purpose of ksycoca is to find out easily "what are the applications
associated with a given mimetype, by order of (user, otherwise desktop-
dependent default) preference". Without a cache, for mimetypes not listed in
any preference file, you have to iterate over a large number of desktop files to
find out which ones support it.
Another purpose is to organize the desktop files in a tree that is shown in the
K menu (based on Categories and that menu definition XML stuff). Without a
cache, the performance will be horrendous, won't it?
You can remove everything about "service types" from ksycoca if no plugin is
represented by a desktop file anymore, but I would advise against removing the
cache of application desktop files. IMHO, if you do, you'll end up
reimplementing a different one anyway at some point.
> What's the plasma startup performance with and without sycoca on a
> clean user
You're going to move the menu generation code to plasma just to measure that
it's slower? ;-)
> I wonder if we should also try to get David Faure to look at this
> thread.
If it was on kde-frameworks-devel I would have seen it earlier, without having
to be pointed to it ;). I thought we moved KF tech discussions to k-f-d and
kept k-c-d for more global stuff like "please review app X before it can go
into module Y" or other process stuff.
--
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20240217/0cdac23c/attachment.sig>
More information about the kde-core-devel
mailing list