D25743: Expose IndexerState enum to QML
justinzobel added a comment. Can we please continue this over on Gitlab? REPOSITORY R293 Baloo BRANCH master REVISION DETAIL https://phabricator.kde.org/D25743 To: davidedmundson, #baloo, ngraham Cc: justinzobel, bruns, broulik, kde-frameworks-devel, ngraham, #baloo, hurikhan77, lots0logs, LeGast00n, cblack, fbampaloukas, domson, ashaposhnikov, michaelh, spoorun, abrahams
KDE CI: Frameworks » plasma-framework » kf5-qt5 SUSEQt5.15 - Build # 279 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20SUSEQt5.15/279/ Project: kf5-qt5 SUSEQt5.15 Date of build: Mon, 21 Dec 2020 19:23:50 + Build duration: 5 min 58 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Plasma-5.78.0.xmlacc/KF5PlasmaQuick-5.78.0.xmlcompat_reports/KF5Plasma_compat_report.htmllogs/KF5Plasma/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report44% (8/18)36% (49/136)36% (49/136)34% (4662/13649)26% (2300/8819)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests92% (11/12)92% (11/12)94% (872/928)48% (378/784)src.declarativeimports.calendar0% (0/6)0% (0/6)0% (0/485)0% (0/201)src.declarativeimports.core47% (8/17)47% (8/17)34% (810/2400)27% (378/1421)src.declarativeimports.plasmacomponents0% (0/6)0% (0/6)0% (0/523)0% (0/195)src.declarativeimports.plasmaextracomponents0% (0/4)0% (0/4)0% (0/43)0% (0/16)src.declarativeimports.platformcomponents0% (0/3)0% (0/3)0% (0/61)0% (0/14)src.declarativeimports.platformcomponents.utils0% (0/2)0% (0/2)0% (0/14)0% (0/2)src.plasma41% (11/27)41% (11/27)42% (1594/3780)34% (894/2653)src.plasma.packagestructure43% (3/7)43% (3/7)36% (49/137)42% (5/12)src.plasma.private45% (9/20)45% (9/20)47% (768/1625)37% (355/951)src.plasma.scripting33% (1/3)33% (1/3)12% (20/173)7% (7/105)src.plasmapkg0% (0/1)0% (0/1)0% (0/45)0% (0/40)src.plasmaquick38% (5/13)38% (5/13)27% (518/1920)18% (278/1511)src.plasmaquick.private50% (1/2)50% (1/2)29% (31/106)36% (5/14)src.scriptengines.qml.plasmoid0% (0/8)0% (0/8)0% (0/1254)0% (0/882)tests.dpi0% (0/2)0% (0/2)0% (0/21)0%
KDE CI: Frameworks » plasma-framework » kf5-qt5 SUSEQt5.14 - Build # 27 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20SUSEQt5.14/27/ Project: kf5-qt5 SUSEQt5.14 Date of build: Mon, 21 Dec 2020 19:23:46 + Build duration: 5 min 33 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Plasma-5.78.0.xmlacc/KF5PlasmaQuick-5.78.0.xmlcompat_reports/KF5Plasma_compat_report.htmllogs/KF5Plasma/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report44% (8/18)36% (49/136)36% (49/136)34% (4663/13649)26% (2300/8819)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests92% (11/12)92% (11/12)94% (873/928)48% (378/784)src.declarativeimports.calendar0% (0/6)0% (0/6)0% (0/485)0% (0/201)src.declarativeimports.core47% (8/17)47% (8/17)34% (810/2400)27% (378/1421)src.declarativeimports.plasmacomponents0% (0/6)0% (0/6)0% (0/523)0% (0/195)src.declarativeimports.plasmaextracomponents0% (0/4)0% (0/4)0% (0/43)0% (0/16)src.declarativeimports.platformcomponents0% (0/3)0% (0/3)0% (0/61)0% (0/14)src.declarativeimports.platformcomponents.utils0% (0/2)0% (0/2)0% (0/14)0% (0/2)src.plasma41% (11/27)41% (11/27)42% (1594/3780)34% (894/2653)src.plasma.packagestructure43% (3/7)43% (3/7)36% (49/137)42% (5/12)src.plasma.private45% (9/20)45% (9/20)47% (768/1625)37% (355/951)src.plasma.scripting33% (1/3)33% (1/3)12% (20/173)7% (7/105)src.plasmapkg0% (0/1)0% (0/1)0% (0/45)0% (0/40)src.plasmaquick38% (5/13)38% (5/13)27% (518/1920)18% (278/1511)src.plasmaquick.private50% (1/2)50% (1/2)29% (31/106)36% (5/14)src.scriptengines.qml.plasmoid0% (0/8)0% (0/8)0% (0/1254)0% (0/882)tests.dpi0% (0/2)0% (0/2)0% (0/21)0%
KDE CI: Frameworks » plasma-framework » kf5-qt5 FreeBSDQt5.15 - Build # 277 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20FreeBSDQt5.15/277/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Mon, 21 Dec 2020 19:24:30 + Build duration: 2 min 9 sec and counting JUnit Tests Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest
KDE CI: Frameworks » plasma-framework » kf5-qt5 FreeBSDQt5.15 - Build # 276 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20FreeBSDQt5.15/276/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Mon, 21 Dec 2020 19:16:54 + Build duration: 7 min 31 sec and counting JUnit Tests Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest
KDE CI: Frameworks » plasma-framework » kf5-qt5 SUSEQt5.15 - Build # 278 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20SUSEQt5.15/278/ Project: kf5-qt5 SUSEQt5.15 Date of build: Mon, 21 Dec 2020 19:16:54 + Build duration: 6 min 55 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Plasma-5.78.0.xmlacc/KF5PlasmaQuick-5.78.0.xmlcompat_reports/KF5Plasma_compat_report.htmllogs/KF5Plasma/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report44% (8/18)36% (49/136)36% (49/136)34% (4663/13649)26% (2300/8819)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests92% (11/12)92% (11/12)94% (873/928)48% (378/784)src.declarativeimports.calendar0% (0/6)0% (0/6)0% (0/485)0% (0/201)src.declarativeimports.core47% (8/17)47% (8/17)34% (810/2400)27% (378/1421)src.declarativeimports.plasmacomponents0% (0/6)0% (0/6)0% (0/523)0% (0/195)src.declarativeimports.plasmaextracomponents0% (0/4)0% (0/4)0% (0/43)0% (0/16)src.declarativeimports.platformcomponents0% (0/3)0% (0/3)0% (0/61)0% (0/14)src.declarativeimports.platformcomponents.utils0% (0/2)0% (0/2)0% (0/14)0% (0/2)src.plasma41% (11/27)41% (11/27)42% (1594/3780)34% (894/2653)src.plasma.packagestructure43% (3/7)43% (3/7)36% (49/137)42% (5/12)src.plasma.private45% (9/20)45% (9/20)47% (768/1625)37% (355/951)src.plasma.scripting33% (1/3)33% (1/3)12% (20/173)7% (7/105)src.plasmapkg0% (0/1)0% (0/1)0% (0/45)0% (0/40)src.plasmaquick38% (5/13)38% (5/13)27% (518/1920)18% (278/1511)src.plasmaquick.private50% (1/2)50% (1/2)29% (31/106)36% (5/14)src.scriptengines.qml.plasmoid0% (0/8)0% (0/8)0% (0/1254)0% (0/882)tests.dpi0% (0/2)0% (0/2)0% (0/21)0%
KDE CI: Frameworks » plasma-framework » kf5-qt5 SUSEQt5.14 - Build # 26 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20SUSEQt5.14/26/ Project: kf5-qt5 SUSEQt5.14 Date of build: Mon, 21 Dec 2020 19:16:54 + Build duration: 6 min 51 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Plasma-5.78.0.xmlacc/KF5PlasmaQuick-5.78.0.xmlcompat_reports/KF5Plasma_compat_report.htmllogs/KF5Plasma/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.plasma_themetest Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report44% (8/18)36% (49/136)36% (49/136)34% (4663/13649)26% (2300/8819)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests92% (11/12)92% (11/12)94% (873/928)48% (378/784)src.declarativeimports.calendar0% (0/6)0% (0/6)0% (0/485)0% (0/201)src.declarativeimports.core47% (8/17)47% (8/17)34% (810/2400)27% (378/1421)src.declarativeimports.plasmacomponents0% (0/6)0% (0/6)0% (0/523)0% (0/195)src.declarativeimports.plasmaextracomponents0% (0/4)0% (0/4)0% (0/43)0% (0/16)src.declarativeimports.platformcomponents0% (0/3)0% (0/3)0% (0/61)0% (0/14)src.declarativeimports.platformcomponents.utils0% (0/2)0% (0/2)0% (0/14)0% (0/2)src.plasma41% (11/27)41% (11/27)42% (1594/3780)34% (894/2653)src.plasma.packagestructure43% (3/7)43% (3/7)36% (49/137)42% (5/12)src.plasma.private45% (9/20)45% (9/20)47% (768/1625)37% (355/951)src.plasma.scripting33% (1/3)33% (1/3)12% (20/173)7% (7/105)src.plasmapkg0% (0/1)0% (0/1)0% (0/45)0% (0/40)src.plasmaquick38% (5/13)38% (5/13)27% (518/1920)18% (278/1511)src.plasmaquick.private50% (1/2)50% (1/2)29% (31/106)36% (5/14)src.scriptengines.qml.plasmoid0% (0/8)0% (0/8)0% (0/1254)0% (0/882)tests.dpi0% (0/2)0% (0/2)0% (0/21)0%
KDE CI: Frameworks » plasma-framework » kf5-qt5 WindowsMSVCQt5.15 - Build # 113 - Still Failing!
BUILD FAILURE
Build URL
https://build.kde.org/job/Frameworks/job/plasma-framework/job/kf5-qt5%20WindowsMSVCQt5.15/113/
Project:
kf5-qt5 WindowsMSVCQt5.15
Date of build:
Mon, 21 Dec 2020 19:16:54 +
Build duration:
1 min 32 sec and counting
CONSOLE OUTPUT
[...truncated 4515 lines...][2020-12-21T19:17:52.753Z] ./package/contents/ui[2020-12-21T19:17:52.753Z] ./package/contents/ui/main.qml[2020-12-21T19:17:52.753Z] ./package/metadata.desktop[2020-12-21T19:17:52.753Z] ./plugin[2020-12-21T19:17:52.753Z] ./plugin/%{APPNAMELC}plugin.cpp[2020-12-21T19:17:52.753Z] ./plugin/%{APPNAMELC}plugin.h[2020-12-21T19:17:52.753Z] ./plugin/CMakeLists.txt[2020-12-21T19:17:52.753Z] ./plugin/qmldir[2020-12-21T19:17:52.753Z] ./qml-plasmoid-with-qml-extension.kdevtemplate[2020-12-21T19:17:52.753Z] ./README[2020-12-21T19:17:53.051Z] [275/469] Generating plasma-wallpaper-with-qml-extension.tar.bz2[2020-12-21T19:17:53.051Z] .[2020-12-21T19:17:53.051Z] ./CMakeLists.txt[2020-12-21T19:17:53.051Z] ./LICENSES[2020-12-21T19:17:53.051Z] ./LICENSES/LGPL-2.1-or-later.txt[2020-12-21T19:17:53.051Z] ./Messages.sh[2020-12-21T19:17:53.051Z] ./package[2020-12-21T19:17:53.051Z] ./package/contents[2020-12-21T19:17:53.051Z] ./package/contents/config[2020-12-21T19:17:53.051Z] ./package/contents/config/main.xml[2020-12-21T19:17:53.051Z] ./package/contents/ui[2020-12-21T19:17:53.051Z] ./package/contents/ui/config.qml[2020-12-21T19:17:53.051Z] ./package/contents/ui/main.qml[2020-12-21T19:17:53.051Z] ./package/metadata.desktop[2020-12-21T19:17:53.051Z] ./plasma-wallpaper-with-qml-extension.kdevtemplate[2020-12-21T19:17:53.051Z] ./plugin[2020-12-21T19:17:53.051Z] ./plugin/%{APPNAMELC}plugin.cpp[2020-12-21T19:17:53.051Z] ./plugin/%{APPNAMELC}plugin.h[2020-12-21T19:17:53.051Z] ./plugin/CMakeLists.txt[2020-12-21T19:17:53.051Z] ./plugin/qmldir[2020-12-21T19:17:53.051Z] ./README[2020-12-21T19:17:53.051Z] [276/469] Building CXX object src\plasmapkg\CMakeFiles\plasmapkg2.dir\plasmapkg2_autogen\mocs_compilation.cpp.obj[2020-12-21T19:17:57.945Z] [277/469] Building CXX object src\plasmapkg\CMakeFiles\plasmapkg2.dir\main.cpp.obj[2020-12-21T19:17:57.945Z] [278/469] Generating src/plasma/KF5Plasma.qch, src/plasma/KF5Plasma.tags[2020-12-21T19:18:07.160Z] [279/469] Automatic MOC for target platformcomponentsplugin[2020-12-21T19:18:07.160Z] [280/469] Linking CXX executable bin\plasmapkg2.exe[2020-12-21T19:18:07.160Z] [281/469] Automatic MOC for target calendarplugin[2020-12-21T19:18:16.113Z] [282/469] Building CXX object src\declarativeimports\platformcomponents\CMakeFiles\platformcomponentsplugin.dir\platformcomponentsplugin_autogen\mocs_compilation.cpp.obj[2020-12-21T19:18:16.397Z] [283/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\calendardata.cpp.obj[2020-12-21T19:18:16.397Z] [284/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\eventdatadecorator.cpp.obj[2020-12-21T19:18:16.397Z] [285/469] Automatic MOC for target KF5Plasma[2020-12-21T19:18:16.665Z] [286/469] Building CXX object src\declarativeimports\platformcomponents\CMakeFiles\platformcomponentsplugin.dir\application.cpp.obj[2020-12-21T19:18:16.665Z] [287/469] Generating libplasma-theme-global.h, libplasma-theme-global.cpp[2020-12-21T19:18:16.665Z] [288/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\calendarplugin_autogen\mocs_compilation.cpp.obj[2020-12-21T19:18:16.665Z] [289/469] Building CXX object src\declarativeimports\platformcomponents\CMakeFiles\platformcomponentsplugin.dir\icondialog.cpp.obj[2020-12-21T19:18:16.665Z] [290/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\eventpluginsmanager.cpp.obj[2020-12-21T19:18:16.665Z] [291/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\calendar.cpp.obj[2020-12-21T19:18:16.926Z] [292/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\daysmodel.cpp.obj[2020-12-21T19:18:18.383Z] [293/469] Building CXX object src\declarativeimports\platformcomponents\CMakeFiles\platformcomponentsplugin.dir\platformextensionplugin.cpp.obj[2020-12-21T19:18:18.670Z] [294/469] Building CXX object src\declarativeimports\calendar\CMakeFiles\calendarplugin.dir\calendarplugin.cpp.obj[2020-12-21T19:18:18.972Z] [295/469] Building CXX object src\plasma\CMakeFiles\KF5Plasma.dir\packagestructure.cpp.obj[2020-12-21T19:18:19.281Z] [296/469] Building CXX object src\plasma\CMakeFiles\KF5Plasma.dir\datacontainer.cpp.obj[2020-12-21T19:18:19.281Z] [297/469] Building CXX object src\plasma\CMakeFiles\KF5Plasma.dir\KF5Plasma_autogen\mocs_compilation.cpp.obj[2020-12-21T19:18:19.281Z] [298/469] Building CXX object src\plasma\CMakeFiles\KF5Plasma.dir\package.cpp.obj[2020-12-21T19:18:19.281Z] [299/469] Building CXX object src\plasma\CMakeFiles\KF5Plasma.dir\private\datacontainer_p.cpp.obj[2020-12-21T19:18:20.337Z] [300/469] Building
Re: KDE review for KWeatherCore
El dilluns, 21 de desembre de 2020, a les 7:16:09 CET, hanyoung va escriure: > KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for > querying weather forecast data. > During the development of KWeather, we found the need to have a weather > library. > KWeatherCore is the result of extracting weather data fetching code from > KWeather. > I think having a dedicated weather library can serve the following propose: > - simplify the KWeather code > - easier to develop a weather daemon > - potentially less code duplication across KDE There's quite some things that need improvement: * You don't have d-pointer in most of the public classes * You have quite some code inline in the .h which makes keeping BC harder * You return const Q* & which is not usual in Qt classes locationquerytest is unstable https://paste.debian.net/1177864/ You have a script that extracts translations to libkweather5 but then you do -DTRANSLATION_DOMAIN=\"kweathercore5\" Cheers, Albert > > Many of you may have already seen my previous email to kde-devel mailing list. > Thank you for your constructive suggestions. Here are something I want to > clarify: > > > I would also propose to consider doing a demon instead, so different > > programs/processes all interested in weather forecast data could share the > > data > The end goal is a daemon indeed, but we want to build the daemon upon the > library. This would give us flexibility > in the future if we don't want a daemon. At least KWeather and other > projects can still benefit from the code. > > > but we want to make sure we don't end up with two things. > I admit there are some overlapped functionalities. But KWeatherCore isn't > designed as a weather data provider as Weather DataEngine. > Instead, it's trying to be the building block of weather related > applications. KWeatherCore saves you the hassle of > dealing with APIs, getting locations and converting timezone. You can build > a daemon with it, or you can > use it in your applications. For example, KItinerary and KWeather use the > same weather API, but don't share code. > That means two code base to maintain. Regarding the dynamic nature of > online APIs, it's better to have one library, > so other applications don't need to be worried about their APIs being > depraved, and they aren't able to update it in time. > > Though not currently implemented, KWeatherCore does intend to have weather > alerts added. We hope it can be done in this Sok > https://community.kde.org/SoK/Ideas/2021#KWeather > With this bit added, then the work on weather daemon can be started. > > Regards, > Han Young > >
Re: KDE review for KWeatherCore
Would it be possible for KweatherCore to lean on location services like Geoclue? (And/if should we be working on a KDE GUI for Geoclue to help with this? That way Kweather could only be dealing with resolving weather info) On Sunday, December 20, 2020 10:16:09 PM PST hanyoung wrote: > KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for > querying weather forecast data. During the development of KWeather, we > found the need to have a weather library. KWeatherCore is the result of > extracting weather data fetching code from KWeather. I think having a > dedicated weather library can serve the following propose: - simplify the > KWeather code > - easier to develop a weather daemon > - potentially less code duplication across KDE > > Many of you may have already seen my previous email to kde-devel mailing > list. > Thank you for your constructive suggestions. Here are something I want to clarify: > > I would also propose to consider doing a demon instead, so different > > programs/processes all interested in weather forecast data could share the > > data > > The end goal is a daemon indeed, but we want to build the daemon upon the > library. This would give us flexibility in the future if we don't want a > daemon. At least KWeather and other projects can still benefit from the > code. > > but we want to make sure we don't end up with two things. > > I admit there are some overlapped functionalities. But KWeatherCore isn't > designed as a weather data provider as Weather DataEngine. Instead, it's > trying to be the building block of weather related applications. > KWeatherCore saves you the hassle of dealing with APIs, getting locations > and converting timezone. You can build a daemon with it, or you can use it > in your applications. For example, KItinerary and KWeather use the same > weather API, but don't share code. That means two code base to maintain. > Regarding the dynamic nature of online APIs, it's better to have one > library, so other applications don't need to be worried about their APIs > being depraved, and they aren't able to update it in time. > > Though not currently implemented, KWeatherCore does intend to have weather > alerts added. We hope it can be done in this Sok > https://community.kde.org/SoK/Ideas/2021#KWeather > With this bit added, then the work on weather daemon can be started. > > Regards, > Han Young signature.asc Description: This is a digitally signed message part.
D23842: [KCompletion] Port away from deprecated methods in Qt 5.14
kossebau added inline comments. INLINE COMMENTS > kcombobox.cpp:363 > +connect(d->klineEdit, ::completionBoxActivated, > +this, QOverload QString&>::of(::textActivated)); > +#endif Why the `QOverload::of()` with `::textActivated`? Accidental copy? After all the purpose of the new signals is to get rid of the overloading, no? REPOSITORY R284 KCompletion REVISION DETAIL https://phabricator.kde.org/D23842 To: dfaure, cfeck, dhaumann, aacid, vkrause Cc: kossebau, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: KDE review for KWeatherCore
Am Montag, 21. Dezember 2020, 15:45:22 CET schrieb Nicolas Fella: > On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote: > > My idea/proposal there is that the library internally makes use of that > > demon. So code which uses KWeatherCore does not need to know that > > implementation-wise there is a demon (which might also need to be a > > build-time option, think app bundles who do not like separate demon > > processes). > > So the demon would not use KWeatherCore, but be a(n optional) backend part > > of it. > > Please keep in mind that having such a daemon would be challenging to > impossible to implement on Android and possibly other platforms as well. That's what I tried to hint at with "(which might also need to be a build-time option, think app bundles who do not like separate demon processes)." > Let's not overengineer the wheel without having to and focus on use > cases relevant for our current apps and less on hypothetical use cases. A demon is not overengineered for this purpose IMHO, and I had thought quite a bit how to overhaul the Plasma weather dataengine to make it sanely reusable as system-wide service, just never got to the editor to implement things. But those who do the code decide and can apply their favourite architectures and whatever makes reaching a working product for them faster :) Cheers Friedrich
Re: KDE review for KWeatherCore
On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote: Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung: KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for querying weather forecast data. During the development of KWeather, we found the need to have a weather library. KWeatherCore is the result of extracting weather data fetching code from KWeather. I think having a dedicated weather library can serve the following propose: - simplify the KWeather code - easier to develop a weather daemon - potentially less code duplication across KDE Many of you may have already seen my previous email to kde-devel mailing list. Thank you for your constructive suggestions. Here are something I want to clarify: I would also propose to consider doing a demon instead, so different programs/processes all interested in weather forecast data could share the data The end goal is a daemon indeed, but we want to build the daemon upon the library. This would give us flexibility in the future if we don't want a daemon. At least KWeather and other projects can still benefit from the code. My idea/proposal there is that the library internally makes use of that demon. So code which uses KWeatherCore does not need to know that implementation-wise there is a demon (which might also need to be a build-time option, think app bundles who do not like separate demon processes). So the demon would not use KWeatherCore, but be a(n optional) backend part of it. Please keep in mind that having such a daemon would be challenging to impossible to implement on Android and possibly other platforms as well. Let's not overengineer the wheel without having to and focus on use cases relevant for our current apps and less on hypothetical use cases. Cheers Nico
Re: KDE review for KWeatherCore
Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung: > KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for > querying weather forecast data. During the development of KWeather, we > found the need to have a weather library. KWeatherCore is the result of > extracting weather data fetching code from KWeather. I think having a > dedicated weather library can serve the following propose: - simplify the > KWeather code > - easier to develop a weather daemon > - potentially less code duplication across KDE > > Many of you may have already seen my previous email to kde-devel mailing > list. > Thank you for your constructive suggestions. Here are something I want to clarify: > > I would also propose to consider doing a demon instead, so different > > programs/processes all interested in weather forecast data could share the > > data > > The end goal is a daemon indeed, but we want to build the daemon upon the > library. This would give us flexibility in the future if we don't want a > daemon. At least KWeather and other projects can still benefit from the > code. My idea/proposal there is that the library internally makes use of that demon. So code which uses KWeatherCore does not need to know that implementation-wise there is a demon (which might also need to be a build-time option, think app bundles who do not like separate demon processes). So the demon would not use KWeatherCore, but be a(n optional) backend part of it. To give you more ideas: I would also envision there could be proxy servers one day. Think of big organizations with lots of devices at same location due to lots of people in same buildings, so interested in the same local weather data, like schools, office-heavy companies, they could have a single proxy server and all clients would just use that proxy, saving the weather/ environment service provider some bandwidth, also adding some privacy layer onto the provider. If KWeatherCore would be prepared to handle that scenario in one way or the other, even better. > > but we want to make sure we don't end up with two things. > I admit there are some overlapped functionalities. But KWeatherCore isn't > designed as a weather data provider as Weather DataEngine. Instead, it's > trying to be the building block of weather related applications. Consider a DataEngine to be some kind of Plasma-specific type of library, as in, as shared logic module, just with a normalized API. This technology though failed to stay in developers' hearts, and these days is deprecated and instead all DataEngines are turned into plain C++ libraries with specific API. The Plasma weather dataengine from plasma-workspace/dataengines/weather might have already been turned into a library similar to kweathercore, just that the last maintainer (me) was attracted by other even more interesting stuff and no-one had picked up so far. See also https://phabricator.kde.org/T13349 Looking at the current API of KWeatherCore, e.g. KWeatherCore::WeatherForecastSource, I think the Plasma Weather DataEngine and KWeatherCore are very much overlapping, other than the one being a Plasma "library" and the other a normal C++ library. With KWeatherCore now thankfully being created by yours, the weather data related features of the weather dataengine would be ideally merged into KWeatherCore, so that the weather dataengine itself can then be deprecated and all existing weather DataEngine consumers (like kdeplasma-addons/applets/ weather or some on https://store.kde.org/browse/cat/424) could be ported to something based on KWeatherCore (I guess there would be some kind of KWeather qml plugin then for these, next to the KWeatherCore library itself). You will find the normalized data model used by the DataEngine here in the class documentation, which then would ideally be merged into the normalized data model of KWeatherCore, so the existing applets would not need that much porting but get data close to what they are using now: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/ weather/ions/ion.h (that normalized data model BTW lacks support for sub-day-granularity for forecasts (like day & night as available with the Canadian service, resulting in bad hack and resulting display in the Plasma applets when using that service), so with room for improvements itself) The weather dataengine also has a plugin mechanism (using DataEngines again for some perhaps random reason, just ignore that) to allow adding support for further weather data provider services by 3rd-party. Such an extension feature would be also nice to have with KWeatherCore. Some more info also here: https://frinring.wordpress.com/2016/04/02/plasma-weather-widget-code-template-available-to-add-your-favorite-weather-data-provider/ Then as Volker already pointed out in good detail, using non-KDE service providers on the internet comes with lots of traps, related to privacy and terms of usage
KDE CI: Frameworks » purpose » kf5-qt5 SUSEQt5.15 - Build # 55 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/purpose/job/kf5-qt5%20SUSEQt5.15/55/ Project: kf5-qt5 SUSEQt5.15 Date of build: Mon, 21 Dec 2020 14:13:13 + Build duration: 4 min 17 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Purpose-5.78.0.xmlcompat_reports/KF5Purpose_compat_report.htmllogs/KF5Purpose/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s) Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report23% (5/22)31% (15/48)31% (15/48)24% (493/2095)19% (179/953)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests100% (2/2)100% (2/2)98% (148/151)59% (54/92)src100% (9/9)100% (9/9)68% (261/384)49% (96/197)src.externalprocess0% (0/2)0% (0/2)0% (0/136)0% (0/98)src.fileitemactionplugin0% (0/1)0% (0/1)0% (0/25)0% (0/18)src.plugins.bluetooth0% (0/1)0% (0/1)0% (0/32)0% (0/8)src.plugins.email0% (0/1)0% (0/1)0% (0/65)0% (0/24)src.plugins.imgur0% (0/2)0% (0/2)0% (0/184)0% (0/63)src.plugins.kdeconnect0% (0/1)0% (0/1)0% (0/31)0% (0/6)src.plugins.kdeconnect_sms0% (0/1)0% (0/1)0% (0/16)0% (0/2)src.plugins.ktp-sendfile0% (0/1)0% (0/1)0% (0/28)0% (0/6)src.plugins.pastebin0% (0/1)0% (0/1)0% (0/54)0% (0/23)src.plugins.phabricator0% (0/3)0% (0/3)0% (0/219)0% (0/74)src.plugins.phabricator.quick0% (0/5)0% (0/5)0% (0/93)0% (0/48)src.plugins.phabricator.tests0% (0/1)0% (0/1)0% (0/60)0% (0/22)src.plugins.reviewboard0% (0/3)0% (0/3)0% (0/229)0% (0/70)src.plugins.reviewboard.quick0% (0/7)0% (0/7)0% (0/154)0% (0/80)src.plugins.saveas100% (1/1)100% (1/1)57% (29/51)61%
KDE CI: Frameworks » purpose » kf5-qt5 SUSEQt5.14 - Build # 9 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/purpose/job/kf5-qt5%20SUSEQt5.14/9/ Project: kf5-qt5 SUSEQt5.14 Date of build: Mon, 21 Dec 2020 14:13:13 + Build duration: 2 min 39 sec and counting BUILD ARTIFACTS abi-compatibility-results.yamlacc/KF5Purpose-5.78.0.xmlcompat_reports/KF5Purpose_compat_report.htmllogs/KF5Purpose/5.78.0/log.txt JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s) Cobertura Report Project Coverage Summary Name PackagesFilesClassesLinesConditionalsCobertura Coverage Report23% (5/22)31% (15/48)31% (15/48)24% (493/2095)19% (177/953)Coverage Breakdown by Package Name FilesClassesLinesConditionalsautotests100% (2/2)100% (2/2)98% (148/151)57% (52/92)src100% (9/9)100% (9/9)68% (261/384)49% (96/197)src.externalprocess0% (0/2)0% (0/2)0% (0/136)0% (0/98)src.fileitemactionplugin0% (0/1)0% (0/1)0% (0/25)0% (0/18)src.plugins.bluetooth0% (0/1)0% (0/1)0% (0/32)0% (0/8)src.plugins.email0% (0/1)0% (0/1)0% (0/65)0% (0/24)src.plugins.imgur0% (0/2)0% (0/2)0% (0/184)0% (0/63)src.plugins.kdeconnect0% (0/1)0% (0/1)0% (0/31)0% (0/6)src.plugins.kdeconnect_sms0% (0/1)0% (0/1)0% (0/16)0% (0/2)src.plugins.ktp-sendfile0% (0/1)0% (0/1)0% (0/28)0% (0/6)src.plugins.pastebin0% (0/1)0% (0/1)0% (0/54)0% (0/23)src.plugins.phabricator0% (0/3)0% (0/3)0% (0/219)0% (0/74)src.plugins.phabricator.quick0% (0/5)0% (0/5)0% (0/93)0% (0/48)src.plugins.phabricator.tests0% (0/1)0% (0/1)0% (0/60)0% (0/22)src.plugins.reviewboard0% (0/3)0% (0/3)0% (0/229)0% (0/70)src.plugins.reviewboard.quick0% (0/7)0% (0/7)0% (0/154)0% (0/80)src.plugins.saveas100% (1/1)100% (1/1)57% (29/51)61%
KDE CI: Frameworks » purpose » kf5-qt5 FreeBSDQt5.15 - Build # 51 - Fixed!
BUILD SUCCESS Build URL https://build.kde.org/job/Frameworks/job/purpose/job/kf5-qt5%20FreeBSDQt5.15/51/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Mon, 21 Dec 2020 14:13:13 + Build duration: 1 min 37 sec and counting JUnit Tests Name: projectroot Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)
Re: KDE review for KWeatherCore
Having implemented the weather support for Itinerary, rebasing that onto a more comprehensive framework would indeed be welcome :) I haven't looked too deeply at the implementation or the API yet, most of the feedback below is based on things learned when implementing this for Itinerary. ## api.met.no license and ToS compliance The data is coming from the Norwegian Meteorological Institute, CC-licensed and with an API that doesn't require authentication, well documented and with a mailinglist for service changes and roadmap/disruption announcements. As far as implementing Open Data by organizations/public administration goes this is exemplary and unfortunately quite rare. So at the very least we should follow their license and terms of services as close as possible, in letter and in spirit. Not all of that can be ensured by the library, some of this needs to be handled by the application. In the latter case those requirements need to be clearly documented though. In particular I remember implementing the following aspects: (1) add a point of contact to the User-Agent header, in case your client misbehaves. I only see this done in one place, https://invent.kde.org/ libraries/kweathercore/-/blob/master/src/weatherforecastsource.cpp#L52, which looks suspiciously like a verbatim copy from Itinerary, without even adjusting the contact address. (2) Request throttling. The ToS seem to have been changed in wording since I last looked at this, but the requirement is still similar: Ensure we don't run unnecessary many queries. The Itinerary implementation uses a random interval between 120-150 minutes as lower bound, based on previous suggestions in the ToS. The already suggested daemon is one way to ensure this globally, however I'm very reluctant to suggest a daemon for this, considering the deployment issues this causes for e.g. Flatpak or APKs. Itinerary uses a simple file cache and file mtimes, something like this should also hold up in a multi-process setup with a bit of extra care I think. (3) Attribution, as required by the CC-BY license. This has to happen in the UI, but as a library user I need to know about this requirement, so this needs prominent mention in the docs I'd say. See https://api.met.no/doc/TermsOfService for more details. I also see other services used there I'm not familiar with, are we complying with their licenses and terms of services? ## Privacy considerations (1) Requested geo coordinates are passed to the online API as-is, ie. this is potentially leaking a high-resolution position of the user to the outside. We can't avoid this entirely obviously, but we can reduce the impact by reducing the coordinate resolution. Itinerary uses 1/10th of a degree for this, which unless you get close to the poles are areas of a few kilometers in size, ie. rather than leaking your home address it's only leaking your home town. (2) What does the sunrise API offer beyond the existing sunrise API we have in KF5::Holidays? The latter has the advantage of doing the entire calculation locally. See https://api.kde.org/frameworks/kholidays/html/ namespaceKHolidays_1_1SunRiseSet.html (3) Similarly, we do have a full offline implementation for timezone lookup by geo coordinates here: https://api.kde.org/kdepim/kitinerary/html/ namespaceKItinerary_1_1KnowledgeDb.html#ac409f468badee3c05438695009d7c67f (4) There are http: only requests send to api.geonames.org it seems. Similarly as with the compliance point, some of this can be argued to be the job of the using application. It would seem safer though is the library would try to avoid mistakes to begin with. ## Other observations (1) The license seems to be GPL-2.0-or-later, which is incompatible with the Frameworks license policy. See https://community.kde.org/Policies/ Licensing_Policy (2) The result types (DailyForecast, HourlyForecast, etc) might benefit from being Q_GADGETs and having Q_PROPERTYs added, so they can be directly consumed by QML? (3) binary compatibility measures seem to be missing in a number of places: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B Regards, Volker On Montag, 21. Dezember 2020 07:16:09 CET hanyoung wrote: > KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for > querying weather forecast data. During the development of KWeather, we > found the need to have a weather library. KWeatherCore is the result of > extracting weather data fetching code from KWeather. I think having a > dedicated weather library can serve the following propose: - simplify the > KWeather code > - easier to develop a weather daemon > - potentially less code duplication across KDE > > Many of you may have already seen my previous email to kde-devel mailing > list. > Thank you for your constructive suggestions. Here are something I want to clarify: > > I would also propose to consider doing a demon instead, so different > >
KDE review for KWeatherCore
KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for querying weather forecast data. During the development of KWeather, we found the need to have a weather library. KWeatherCore is the result of extracting weather data fetching code from KWeather. I think having a dedicated weather library can serve the following propose: - simplify the KWeather code - easier to develop a weather daemon - potentially less code duplication across KDE Many of you may have already seen my previous email to kde-devel mailing list. Thank you for your constructive suggestions. Here are something I want to clarify: > I would also propose to consider doing a demon instead, so different > programs/processes all interested in weather forecast data could share the > data The end goal is a daemon indeed, but we want to build the daemon upon the library. This would give us flexibility in the future if we don't want a daemon. At least KWeather and other projects can still benefit from the code. > but we want to make sure we don't end up with two things. I admit there are some overlapped functionalities. But KWeatherCore isn't designed as a weather data provider as Weather DataEngine. Instead, it's trying to be the building block of weather related applications. KWeatherCore saves you the hassle of dealing with APIs, getting locations and converting timezone. You can build a daemon with it, or you can use it in your applications. For example, KItinerary and KWeather use the same weather API, but don't share code. That means two code base to maintain. Regarding the dynamic nature of online APIs, it's better to have one library, so other applications don't need to be worried about their APIs being depraved, and they aren't able to update it in time. Though not currently implemented, KWeatherCore does intend to have weather alerts added. We hope it can be done in this Sok https://community.kde.org/SoK/Ideas/2021#KWeather With this bit added, then the work on weather daemon can be started. Regards, Han Young
