KService as a platform abstraction framework?

[Alexander Lohnau]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210704/4556eb9f/attachment.htm>