Hi, Sorry, I forgot to send the notes. They may also be slightly less detailed than usual, but what matters is that the "needs input" columns is a bit shorter.
----- = https://phabricator.kde.org/T12536 "Rethink notification sounds" There are notes from the KF 6 sprint, but the task is still in "needs inputs". It lists actionable items, so maybe it just needs to be split into smaller tasks. In any case, there are apparently no blockers for KF6. Maybe just one point for discussion: "Port users of popup-less KNotifications to something else" There are some use cases that can be ported to just "play a sound", but there are maybe use cases for keeping it. It shouldn't be a blocker anyway. The support for sound themes may be though. = https://phabricator.kde.org/T12526 "Investigate KMessageBoxNotifyInterface Related to the previous task, two opinions: - just using knotifications to play sounds is wrong - but we lose configurability How do you configure sounds with themes? Create a temporary theme? It is similar to icon theme: drop a file inside the user directory. -> investigate themes and how to properly override them Possible issues with the migration path from the old settings, need to be investigated. -> move to backlog = https://phabricator.kde.org/T11875 "KNotification v2" Memory management problem -> the KF6 migration could be the right time to solve it. (notifications that can stay longer in memory - and produce memory leaks) (some discussion about the implementation details) The notitication moved to the notifyrc file (and getting rid of it, moving the configuration in code). Of the whole task, what are the blocking parts for KF6? The removal of notifyrc may help removing a dependency - if it doesn't leak in the public API, it can be removed later, but it's still a behavioral change. -> move back to backlog, have (KF6 blocker) subtasks for the memory management issue and the removal of notifyrc = https://phabricator.kde.org/T12008 "Screensaver/screen lock inhibition" To be implement it in Qt. How detailed should the APIs be? (see the various use cases in the task description) It should still be possible to prevent inhibition without a window visible. (see for example prevent locking and sleeping if phone is connected in kdeconnect). -> New stuff, no blocker for KF6. Nice to have in Qt. Move to backlog. = https://phabricator.kde.org/T11833 "Overhaul Solid" Maybe slim down and continue using it as it is - but we risk ending up as in the Qt4->Qt5 transition with deprecated code with no replacement. On the other hand an async Solid may be unrealistic for Qt6 given the time constraints. Process-related code may be more easily deprecated and removed. Ensure that anything in kdelibs4support is really unused. Also, see which classes/files need to be cleaned/renamed. Also check which parts of Solid affects the behavior and public APIs of other Frameworks (everything else in an implementation details). -> moved to "needs splitting" -- Luigi