Hello,
regarding the kcmutils core lib discussion I have a quick addition to the topic: KPluginSelector
should get a KPluginMetaData based replacement. This will have a core model and a QML/QWidgets
version. Meaning that it makes sense to introduce a core lib even in KF5 for this new class.
See https://phabricator.kde.org/T12265 for the related task.
Regards
Alex
Gesendet: Dienstag, 26. Oktober 2021 um 18:05 Uhr
Von: "Volker Krause" <vkra...@kde.org>
An: kde-frameworks-devel@kde.org
Betreff: KF6 meeting notes 2021-10-26
Von: "Volker Krause" <vkra...@kde.org>
An: kde-frameworks-devel@kde.org
Betreff: KF6 meeting notes 2021-10-26
!! Meeting will move to 17:00 CET next week (due to DST change in continental
Europe)
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/149
* static plugin support draft, needs review
* MRs to demonstrate the usage exists for KWin and KMyMoney
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/117
* generic ctor vs. named ctor pattern?
* pro named ctor: explicitness, safety, and ability to deprecate indivdual
features
* pro generic ctor: easier for code that supports multiple formats (do we have
that at all?)
* currently no known issues with this
* can be changed later, but having named ctors now might help with porting
* having both at the same time is also possible, as both methods do different
things/solve different use-cases
* postpone until this becomes an actual problem
https://phabricator.kde.org/T14517
* JSON KCM loading works fine
* URL to pin KCMs to taskbar requires a .desktop file
* would require to keep the .desktop files around for KCMs that behave
"application-like"
* generate .desktop file from JSON, to avoid duplication?
* would the JSON file have all the necessary content?
* alternative: manually maintained .desktop files
* not an alternative: keep .desktop-based plugin loading code and json from
desktop generation around
https://phabricator.kde.org/T14763
* should we already install unversioned symlinks for CLI tools right now?
* unversioned implies CLI interface compatibility
* should have done a long time ago, so yes, do this now
* kcmshell will move to kcmutils and become versioned
https://phabricator.kde.org/T14367
* QML bindings from KDeclarative and KCMModule from KConfigWidgets planned to
move to KCMUtils (https://phabricator.kde.org/T12150)
* should we split KCMUtils internally between classes for creating KCMs and
classes for consuming KCMs (which is where the KXmlGui dependency comes in)?
* dependency on KXmlGui is for KAboutPluginDialog, which is tied to the entire
about dialog code in xml gui
* could we move the entire about dialog stuff down to a tier2 framework? but
there's no good framework there to place this in? but does that even make
sense for something every widget-based app needs anyway?
* so the above suggestions of multiple libs in the kcmutils framework might
make more sense
* related to https://phabricator.kde.org/T14355, which might eventually also
require a core library in KCMUtils
Threaded KIO workers:
* David F is removing the POP3 kioslave to enable that
Europe)
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/149
* static plugin support draft, needs review
* MRs to demonstrate the usage exists for KWin and KMyMoney
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/117
* generic ctor vs. named ctor pattern?
* pro named ctor: explicitness, safety, and ability to deprecate indivdual
features
* pro generic ctor: easier for code that supports multiple formats (do we have
that at all?)
* currently no known issues with this
* can be changed later, but having named ctors now might help with porting
* having both at the same time is also possible, as both methods do different
things/solve different use-cases
* postpone until this becomes an actual problem
https://phabricator.kde.org/T14517
* JSON KCM loading works fine
* URL to pin KCMs to taskbar requires a .desktop file
* would require to keep the .desktop files around for KCMs that behave
"application-like"
* generate .desktop file from JSON, to avoid duplication?
* would the JSON file have all the necessary content?
* alternative: manually maintained .desktop files
* not an alternative: keep .desktop-based plugin loading code and json from
desktop generation around
https://phabricator.kde.org/T14763
* should we already install unversioned symlinks for CLI tools right now?
* unversioned implies CLI interface compatibility
* should have done a long time ago, so yes, do this now
* kcmshell will move to kcmutils and become versioned
https://phabricator.kde.org/T14367
* QML bindings from KDeclarative and KCMModule from KConfigWidgets planned to
move to KCMUtils (https://phabricator.kde.org/T12150)
* should we split KCMUtils internally between classes for creating KCMs and
classes for consuming KCMs (which is where the KXmlGui dependency comes in)?
* dependency on KXmlGui is for KAboutPluginDialog, which is tied to the entire
about dialog code in xml gui
* could we move the entire about dialog stuff down to a tier2 framework? but
there's no good framework there to place this in? but does that even make
sense for something every widget-based app needs anyway?
* so the above suggestions of multiple libs in the kcmutils framework might
make more sense
* related to https://phabricator.kde.org/T14355, which might eventually also
require a core library in KCMUtils
Threaded KIO workers:
* David F is removing the POP3 kioslave to enable that
