KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 902 - Fixed!

2021-07-04 Thread CI System 
BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/902/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Sun, 04 Jul 2021 10:39:11 +
 Build duration:
3 min 36 sec and counting
   JUnit Tests
  Name: projectroot Failed: 0 test(s), Passed: 59 test(s), Skipped: 0 test(s), Total: 59 test(s)Name: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 901 - Still Unstable!

2021-07-04 Thread CI System 
BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/901/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Sun, 04 Jul 2021 10:29:25 +
 Build duration:
9 min 43 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 58 test(s), Skipped: 0 test(s), Total: 59 test(s)Failed: projectroot.autotests.applicationlauncherjob_servicetestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

Re: KService as a platform abstraction framework?

2021-07-04 Thread 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