KF6 meeting notes 2021-05-22

[Luigi Toscano]

Hi all,

the discussion included questions not linked to any tasks, and tasks from both
"needs input" (ok, just 2) and "backlog". I guess that, going forward, we will
see more tasks from other columns being part of the discussion (the "needs
input" column is shorter and shorter).

----------------------

== General discussion

We started with a few general questions (non directly related to specific tasks)


- KCMUtil and KCM loading

Widget-based KCMs are depracted for systemsettings, which will only support
QML-based ones.
But Widget-based KCMS are still needed in applications (see PIM).

There was a (technical) question about how to maintain the separation between
systemsettings-only KCMs (just QML) and the others.

We may add a method which gets a namespace and systemsettings (or an
application) could use that to find only the KCMs which are relevant for itself.


- Plugins

Question: does anyone have experience with static plugins from Qt?
It seems they require two code paths (one for static, one for dynamic)
They are/will be useful for Android applications.
(some discussion on where to place the utility function do deal with them; in
any case, the new functionality can be added anytime on top of what we have)

Different issue: searching for plugins require the namespace and the plugin
ID, it could be a good idea to use the file name instead of the plugin ID.
This assumes the the file name matches the library name. May it help with
removing the ID from the plugin's json file.
But doesn't loading plugin by name defeat the purpose of a plugin?
It may be useful to load a specific configuration entry.
Exception: static plugin, no file, but then it would need to keep the support
for the plugin ID.

Yet another issue: several applications still use .desktop file converted to
.json as build time.
Would it make sense to convert them to directly use json files.
For KCMs, they are still needed for the deprecated loading (and kbuildsyscoca
doesn't load at json file, so krunner would be broken and so other use cases)

KServiceTypes deprecation: they are used also to document the properties. What
about the documentation, should it be moved to the class documentation? Would
those servicetype definitions even needed with the new system?
In any case, KCoreAddons properly documents the information from the json
files, other libraries may follow that model.

- C++17?

Q. what should we do about it? (see
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/107#note_220712
)
A. Didn't we decide to move forward with C++17?
Only if we enable a specific ECM version, to not break the old code.


== Tasks

And now, the tasks. Only two tasks were from the "needs input" column, the
othersfrom "backlog".


- https://phabricator.kde.org/T11903 "KWayland for KF6"

Plasma team will take care of it
server stuff: already took care of
client side: a bit complicated (some stuff taken care by Qt, or should take of
by Qt)
What's left is easy to do with the structures provided now by Qt
Also, many items in kwayland-integration could be broken out and its parts
moved to the real components where the functions are used.
All in all, it seems there is a specific plan, and no real blockers for KF6.0
-> move to "In progress"


- https://phabricator.kde.org/T13555 "Create replacement for
KPluginInfo::kcmServices"

Sort of done: there is a replacement solution for the KPluginSelector use
case, which could become the reference way for solving that use case, even if
not enforced. Probably no many other users in any case.
The specific items described in the tasks are done -> moved to done


- https://phabricator.kde.org/T14311 "Investigate where std::optional should
be used" (from "backlog")

Isn't it really a metatask? It is not actionable as sit is. Other subtasks to
address specific use cases may be created from it. The task could be also used
to investigate and explain how to use the feature without breaking the code
(with new items in the Frameworks coding style guide).


- https://phabricator.kde.org/T11586 "Deprecate and remove
KTipDatabase/KTipDialog" (from "backlog")

Is the class still needed? Let's follow-up on the discussion linked there.


- https://phabricator.kde.org/T12183 "KService: make some Sycoca method not
exposed to API?" (from "backlog")

Is it a real task, or should it be closed as invalid?
(context: if syscoca ever goes away we don't want ot expose it. It depends on
how it impacts the API. It is really a type definition).
Better wait on dfaure's feedback, let's follow up in the task.


- https://phabricator.kde.org/T13695 "KSettings in KF6"

Related to the initial question about KCM*: would it make sense to write a
json-based replacement for that (to be used again by PIM etc)? Yes. Not in
that namespace though.

-- 
Luigi