KF6 meeting notes 2021-05-08

[Luigi Toscano]

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