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
signature.asc
Description: This is a digitally signed message part.