Re: KService as a platform abstraction framework?
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
Re: KService as a platform abstraction framework?
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
KService as a platform abstraction framework?
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 signature.asc Description: This is a digitally signed message part.
