[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: revisiting the sycoca
From:       David Faure <faure () kde ! org>
Date:       2024-02-17 11:26:40
Message-ID: 6717251.zL2vLDh68u () asterixp15
[Download RAW message or body]


[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@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]