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
