Is this task referring to the // KF6: make it private comments that are in the code?

I think this was about class KSERVICE_EXPORT KService : public KSycocaEntry, which exposes the fact that KService is "backed" by ksycoca, in the public API (given all the methods in KSycocaEntry).

But I don't know how much of a problem it really is -- or will be :)

If we see KService as a functional/platform implementation framework this is probably not much of an issue. If we want KService to become a platform abstraction that also covers systems not based on a .desktop file store and instead also support the native mechanisms on e.g. Android or Windows, the leaking of the sycoca implementation is less ideal, as it prevents us from not including that part on platforms where it isn't needed at all.

I did a quick test to see if this could work:

• make KService inherit privately from KSycocaEntry
• but add these, which are not ksycoca specific (i.e. those methods could be implemented differently on Android) :
  
  using KSycocaEntry::ref; using KSycocaEntry::isValid; using KSycocaEntry::entryPath; using KSycocaEntry::propertyNames; using KSycocaEntry::name;

• and build kservice with -DEXCLUDE_DEPRECATED_BEFORE_AND_AT:STRING=5.85.0

The remaining compile errors come from KServiceGroup, ksycocadict, kbuildsycoca, vfolder_menu. Those are all about filling up sycoca and the K menu, so irrelevant for Android, that could would have to talk directly to the ksycoca backend of KService.

KApplicationTrader would be pretty useless without a sycoca backend though... In other words, this experiment should also disable the KService(stream, int) private constructor at the very end of kservice.h -- and then KServiceFactory fails to build, as expected :)

So: conceptually, I think it would work. But this obviously can't be done in a SC/BC way, it would have to be done in a feature branch.

[but trying to compile kservice with exclude_deprecated... shows that I should start by writing a mail client launcher job...]

Before starting this in a branch, it might be worth adding Android support first (which can be done now I think), I suspect this will identify a number of additional places in the API that would benefit from adjustments/generalizations.

Somewhat related: Every time I use KService I ask myself "Why do we have KService pointers everywhere, that's odd for something that conceptually is a value type"

Well, it was using inheritance, which is frowned upon for value types (due to risk of slicing).

But indeed if we remove the inheritance then we might also turn it into a value class. But then the porting effort increases dramatically.

My suggestion is KApplicationEntry (a value class) and KApplicationEntryTrader (an alternative to KApplicationTrader that returns a KApplicationEntry or a list of those).

On Unix it would encapsulate a KService. On other platforms it would do other things :)

It would live in the kservice framework.