KF6 meeting notes 2021-05-15

[Luigi Toscano]

Hi all,

apologize again for the late report. Luckily most of (if not) all  the
affected tasks have been updated with more accurate summaries already.


== pending ECM task

Before going through the tasks in "needs input" state, we touched again a few
ECM-related tasks already discussed in the past.


- We decided to increase requirements in ECM.
Issues: ECM compiler settings are used by other applications outside KDE, it's
difficult to change.
For example Plasma used the Frameworks settings, but they had to change it as
it started breaking. In the end, applications aren't really meant to use them.
Bump to C++17 is WIP:
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/107
New task for CMake bump: https://phabricator.kde.org/T14467

- Qt5/Qt6 in parallel
Still WIP, still need some discussion on the MR.


== And now the "Needs input" tasks

- https://phabricator.kde.org/T12643 "KAuth: Remove nested event loop in
Polkit1Backend::actionExists()"

Actionable task if people agree with it
The proper fix is about adding an async API - the open question is: it it
really needed?
Maybe not. There is an action plan
-> moved to backlog.


- https://phabricator.kde.org/T12275 "Create QQC2 Equivalent of TableView"

We need a TableView which doesn't use the class which will go away.
Create a something for Frameworks, or try to upstream something in Qt?
kirigami-addons has some code which may be relevant. So the relevant code can
be copied/added there and the porting can start now, in KF5.
-> moved to backlog

- https://phabricator.kde.org/T12234 "KActivities: port away from use of quint
for window ID handling"

We need to find out what exactly is KActvity doing with that value before
moving forward.
Why is the window ID used for? Maybe for launching applications, or
ShareLikeconnect.
This is more a Wayland issue than a KF6 issue, but it potentially affects the API.
In the end, it should be possible to transition to the new way without too
many issues: see the notes in the ticket, there is a plan.
-> moved to backlog


- https://phabricator.kde.org/T12197 "Move KLanguageButton from KConfig ->
QSettings"

One challenge remaining: loading translations in the button which shows the
language.

In the worst case it shouldn't be a lot of code to read the correct language
code (duplicating the code that KConfig has)
We ship those translations, so we can tune the format as we need. There is
also the idea of moving the translations to KI18n. But that would still block
the cleanup of this KConfigWidget.

But in the end, is there a problem of having KLanguageButton in KConfigWidget?

Side note: We may need a tier2 widget framework. How much will this solve? Who
writes code which uses widgets without config?

It still makes sense to move the non-widget part outside of KConfigWidget.
Right now KLanguageButton is only used by KXmlGui, with a few exceptions, but
it is useful in other places.

Suggestion: doen't do anything with KLanguageButton, just fix the source of
the data for now (see the KLocale task)


- https://phabricator.kde.org/T12542 "Fix circular dependency of
applications.menu in KService and plasma-workspace"

(if I've got it correctly) The use case that required it in the past was
related to application launching, which was done through desktop files and a
missing desktop file in the menu could lead to the launcher to not find the
application (workarounded with two separate registries).
But maybe we don't need the application.menu anymore in KService apart from
the unit tests, and it could move to plasma.
-> let's see if that's true; moved to "waiting for KF6"


Ciao
-- 
Luigi