On 03.07.21 10:25, Volker Krause wrote:
Hi,
while looking at implementing a pretty straightforward KApplicationTrader/
KIO::ApplicationLauncherJob use ([1]) for Android, I found myself wondering
whether we should have an Android backend for KService.
KService conceptually matches android.content.pm.PackageManager/PackageInfo
[2, 3], ie. the platform API to list installed applications and their
respective features (essentially what's in the Android manifest XML files). In
detail it however is full of .desktop file specifics, and leaks platform
implementation details (e.g. KService inheriting from sycoca types).
KIO::ApplicationLauncherJob is also something that makes sense conceptually on
Android, implemented on top of Intents there.
Has anyone thought about/looked into using KService as platform abstraction
rather than as an functional/platform implementation framework already? I
could imagine this to also be relevant on Windows.
Is anyone aware of a current use on Android relying on the .desktop based
implementation of KService? That might be theoretically possible, unlike for
ApplicationLauncherJob.
And while retrofitting platform abstraction support into KService wont be
pretty, the alternative approaches (a new abstraction framework on top, or let
applications deal with that with platform-specific code paths) aren't exactly
convincing either.
Thoughts?
Thanks,
Volker
[1] https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/35
[2] https://developer.android.com/reference/android/content/pm/PackageManager
[3] https://developer.android.com/reference/android/content/pm/PackageInfo
Hi,
I think overall it makes sense.
In our ongoing KF6 work we tend to move away from using KService for
non-application cases (plugins and kparts). Assuming we fully execute
that quite a bit of stuff then can be dropped from KService. That should
make it easier to adapt/make it less awkward to retrofit Android support
then. I think it's worth going over the KService class and investigate
how much of it will be relevant on a post-KF6 world.
Some XDG-isms are going to remain, but as long as it's just a bunch of
properties this should not be a big issue.
Cheers
Nico
