- User Since
- Jul 29 2015, 8:38 AM (219 w, 5 d)
The only one remaining I can find (locally and with lxr) is kdelibs4support, which of course makes no sense to port. So I think this is done apart from the actual deletion.
My RPI3 with the Yocto-based Plasma Mobile isn't in the best state as you saw at Akademy, and updating it is somewhat blocked by support for the DSI display being broken upstream currently, ie. the best I can offer is the old version from around FOSDEM 2019. HDMI output works fine still, but I don't have a HDMI touch screen.
Deal with errors with full QSslError level of detail until kssld is ported, make variables const.
This actually breaks things when the error comes from a Qt source rather than a KIO one, as we now carry the QSslError level of detail forward far enough and compare it to the stored KSslError. This is a temporary problem until the kssld side is ported too, but it nevertheless needs a workaround until that is done.
Sat, Oct 12
Upstream fix: https://codereview.qt-project.org/c/qt/qtbase/+/277245
bump version number to 5.64
bump version to 5.64
Fri, Oct 11
Nice! We use the Breeze weather icons in KDE Itinerary too, based on api.met.no data, but so far didn't make use of the wind information in there yet.
Seems to work, and conceptually this makes sense, we don't want to have any product filter active. I suspect it's a leftover I didn't catch when bisecting which of the settings are actually mandatory to get useful a response.
Thu, Oct 10
Wed, Oct 9
Tue, Oct 8
Mon, Oct 7
Solid certainly needs attention for KF6 :)
- Do you see powersave/screen saver inhibition and display brightness control in scope for Solid? If not, where would we put that in KF6? T11532 suggests Solid, this task would suggest something else IIUC.
- How widespread is the usage of the things you suggest to drop? CPU enumeration sounds like something that's only there "because we can", but we should verify nevertheless to avoid repeating the same problem as with the Solid parts still in KDELibs4Support.
Explicitly delete the assignment operator (which has no implementation).
Obviously I'm also interested :)
Thanks for working on this! Some general thoughts:
- Is KDeclarative is the right place for this? It's a module on the way out in KF6, it is hard to build for Android due to its dependency chain (which isn't even needed for this), while at the same time forcing ABI stability on this basically immediately without much chance for battle testing this.
- This currently represents a flat list of calendars, which matches Android IIRC, but not Akonadi (which treats calendars as folders and thus hierarchical). That might not be a problem as long as we treat Akonadi as a single calendar and don't expose the different backends on this level at all, but IIUC @dvratil was argueing to move away from that approach.
Sun, Oct 6
Sat, Oct 5
Ok as such, but there seem to be unrelated changes to test scripts in this commit.