KF6 meeting notes 2021-10-11

[Volker Krause]

!! 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.
-------------- 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/20211011/e0113df7/attachment-0001.sig>