On Saturday, 3 July 2021 19:39:17 CEST Nicolas Fella wrote: > 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
Hi, > In our ongoing KF6 work we tend to move away from using KService for > non-application cases (plugins and kparts). This also includes getting rid of KServiceTypeTrader, which is actively being worked on. Also https://phabricator.kde.org/T12183[1] is related to KService being a platform abstraction framework. Regards Alex -------- [1] https://phabricator.kde.org/T12183#255228