KF6 meeting notes 2021-09-13

[Volker Krause]

Workboard clarification:
- Needs Input is for tasks needing discussion in the weekly meeting
- In Discussion was created during a sprint and should not be used outside of 
a sprint
    
https://phabricator.kde.org/T12549 
- do we need a KConfigXT extension for a setting/state separation? -> yes
-- should this be per XML file, or should this be a per key setting in the XML 
file?
-- non-XT manual use is separated by file, not by key, XT ctors take the file, 
so better do this per XML file
- not limited to the 5 to 6 transition, we don't want data loss even on state 
at any point
- xmlgui might need a virtual method for the separation though, which has to 
happen at the 6 transition

https://phabricator.kde.org/T12533#263299
- good idea, also beyond just the config/state split for replacing 
kconf_update, both in the same file and across two files
- new API should use KConfig objects rather than work on disk like 
KConfig::copyTo, so we also update the in memory representation
- possibly rename KConfigGroup::reparent to moveTo, but should be done in the 
context of a full proposal for per-key move/copy methods

https://phabricator.kde.org/T14844
- static plugin part of this could be solved by a K_IMPORT_PLUGIN macro, but 
that doesn't solve the namespace part
- factory name only matters for staticly importing, so do we need a name at 
all in cases where static plugins don't matter
- set name via a cmake property, use if set or fall back to default/fixed 
name? build-system level access to this enables auto-generated static plugin 
import code
- see also https://phabricator.kde.org/D10333 for the historic origin
- do we need a dedicated macro for non-metadata plugins? could be a useful 
convenience and easy to implement

https://phabricator.kde.org/T12265
- there's still edge cases to iron out
- should we enforce namespaces? not strictly needed for this, but the 
recommended way
- standardize on X-KDE-ConfigModule key to enable migration away from 
KServiceTypeTrader
- KPluginInfo helper function for migration is probably not worth the effort
- go directly for the replacement, no migration aids in KPluginSelector for 
now

https://phabricator.kde.org/T14842
- good idea
- should we use the API hiding macros, as that would take away the entire 
module? or can we do that on the cmake level even?
- we miss documentation for replacements for full-framework deprecations
- for Kross which has a single entry point that's probably the only thing we 
need to go after, but e.g. kdelibs4support is more complicated

https://phabricator.kde.org/T12012
- would require in-process KIO
- see also https://phabricator.kde.org/T12214
- there might be public API tied to out-of-process use
- part of the connected slave API might be unused nowadays (legacy from IMAP 
over KIO) 
-- still in use in the POP3 ioslave (which could be ported away) - https://
lxr.kde.org/source/pim/kdepim-runtime/resources/pop3/jobs.cpp
-- also: UPnP code in Amarok? - https://lxr.kde.org/source/multimedia/amarok/
src/core-impl/collections/upnpcollection/UpnpCollectionBase.cpp - Elisa has a 
separate lib for this
- another blocker: the feature to put slaves on hold - might be obsolete with 
the removal of konqueror as a web browser
- Scheduler/Slave are tied a lot to PIDs internally
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210913/708ac385/attachment.sig>