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