!! Changing the meeting time: - Monday conflicts with Alex's new university schedule and is difficult for David F, would Tuesday at the same time work for everyone instead? -> moved to Tuesday starting next week KF6 Timeline - Plasma needs to know for release planning for 2022 - possible next KF6 phase would be a branching/porting sprint in Q1 or Q2 2022, now that Qt 6.2 is released - beta release details to be decided, once KF6 API is stable enough to be ported to
https://mail.kde.org/pipermail/kde-frameworks-devel/2021-September/118963.html - how to handle deprecation of things we cannot remove right now? - are the existing build/enable deprecation macros good enough for this, or do we need a third mode? probably not, limited gain for a lot of complexitiy - might prevent some frameworks from bumping the deprecation version for one of their dependencies, happens rarely enough to be acceptable https://phabricator.kde.org/T14856#264657 - David to port fsview, which was using the wrong signal for historic reasons - this unblocks removal of the signal overloads Alex's prepared questions: > Generally some progress on the KServiceTypeTrader port for the KCM related > stuff, needs now mostly work on the plasma side. (Both KCM providers and > plasma-settings for the Plasma-Mobile folks) > > https://phabricator.kde.org/T14856 Needs input from dfaure David commented on the ticket > https://invent.kde.org/frameworks/kconfig/-/merge_requests/82 > https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/85 > Opinions? alternative to QQmlPropertyMap would be to copy the entire enum, which is also ugly > I think there is no nicer/more typesafe way to register the enums in the > “KAuthorized” QML. Having an enum in a namespace and then trying to > register it to QML seems challenging. Could it make sense to move > KAuthorized from a namespace to a QObject class and have the methods > static? Relates to https://phabricator.kde.org/T11633 for KF6: make KAuthorized directly exportable in KConfig, by turning it from a namespace into a class/Q_GADGET with static Q_INVOKABLEs, and exported as a QML singleton, which should be source compatible on the C++ side > I think the change would not be noticeable for users. We could make the > constructor private, ad a friend class declaration for the QML plugin and > all is good ;) > I’d like to get https://invent.kde.org/frameworks/kconfig/-/merge_requests/ 81 > in so that it can be used in the kxmlgui MR. fine either way, helper method can be added later as well, David comments on the MR. > Could it also make sense to have a method to rename a key, as ahmadsamir > suggested in https://phabricator.kde.org/T12533 and get rid of https:// > techbase.kde.org/Development/Tools/Using_kconf_update#Example_update_file in > the long run? It seems like it is primarily used by apps to change their own > config – which is what we concluded at the KF6 sprint to be not the usecase > it was intended for. With the utility method methods apps could simply do > the moving themselves and avoid the issues described in the task. If there > is really a usecase where the kconf_update mechanism is needed an executable > which uses the utility methods could be easily implemented. makes sense for replacing kconf_update usage, even if there is no immediate pressure for it right now > https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/138 > Thoughts on this one? If this gets merged I will work on the static plugins > support. David comments on MR, the define name is not part of the API but an implementation name, so naming is good enough.
signature.asc
Description: This is a digitally signed message part.