Inside plasma desktop there's a copy of this Component reading from KPluginMetadata which has a bit less info

This should be done before branching, because we do not want to use a Plasma internal compat library in an application

Whatever we decide we would need an implementation for KEditListWidget https://api.kde.org/frameworks/kwidgetsaddons/html/classKEditListWidget.html

In lots of KCMs we show this on-hover, do we have any consensus regarding that?

Done with https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/124

https://invent.kde.org/system/dolphin/-/merge_requests/359 takes care of Dolphin's servicemenu installer

https://invent.kde.org/plasma/plasma-integration/-/merge_requests/33 moved in the platformtheme
https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/118 deprecates it

If we were to put the Dataengines code in a compat library as part of Plasma (for internal usage), I would argue that it makes sense to deprecate the DataEngine related methods in Plasma::PluginLoader.

This is a bigger change, but I am almost done: https://invent.kde.org/plasma/kdeplasma-addons/-/tree/work/alex/comic_dataengine

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1551

Assigning Kai as we discussed during the sprint :)

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/465 Is the current draft for fixing it on the frameworks side

With the plans to get getting rid of KDeclarative, we should consider not using KIO::AccessManager when creating the alternative.

If you need further help, I can push a change to a Mr/branch if you like

If you need further help, I can push a change to a Mr/branch if you like

You should install a desktop file with the translated name and a few other keys, see https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/autostart/kcm_autostart.desktop#L40 until the end of the file.

why not put the new names into the KRunner namespace?

As discussed with Marco in DM, this will be a done by splitting up plasma-frameworks. Meaning that functionality that is useful outside of plasma will be a frameworks and plasma specific functionality (like activities) will be part of workspace.

Potentially interesting could be the automatic fallback to software rendering also on other platforms

making it happen would be great, but don't want you trying to dig into that without having enough headache tablets in stock ;)

But the question is, where the code should be moved to. It only depends on KConfig/KConfigXT.
Because of this I think cascading configs are seen as a feature here, like trying out different settings for a single app. Because of that moving it to kirigami would not be possible. Though in the KCM plasma-desktop/kcms/qtquicksettings) only kdeglobals are written to

@mart Ping

kde-cli-tools has compat symlinks added in https://invent.kde.org/plasma/kde-cli-tools/-/merge_requests/23

I will need to do some investigation, hopefully I will find the time this week.

Can the init function (and others like it) be ported to some alternative approach that doesn't require users to remember calling this function?

For reference: The mentioned MR only touched the new class, https://invent.kde.org/frameworks/knewstuff/-/merge_requests/158/ adds some further KF6 compatibility code.

@davidedmundson Any progress on this?

Deprecated with:
https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/102

The MR landed, I will take care of porting frameworks to it

And the POC MR: https://invent.kde.org/network/ktorrent/-/merge_requests/48

MRs waiting for Plasma 5.24 branching:
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/790
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1333
https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/105

@leinir Should we register the EntryInternal class with it's enums under the org.kde.newstuff uri? While it it part of the core package, I consider it useful for a lot of consumers.

Considering that we have breakup plans for KDeclarative, we should work on this.

Closing it in favor of T12137

Because the QML port is in progress, I am removing it from the KF6 board

@mart Could you please elaborate on the task?

As I have mentioned on the KF6 weekly, we can already do the cleanup for API users, when we exclude deprecated code and thus the signal overloads.

See T15135

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/176

My current draft is https://invent.kde.org/frameworks/kcoreaddons/-/commit/9f2ac2a144dad6501670a7f52c83229cba769cdb, I will make a MR once https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/166 landed. otherwise creating the plugin factory involves a bit of unnecessary work :)

For reference: https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/175

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/172

Merge request is https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/214

We should still inform consumers about this being removed in KF6, for this a Qt major version visibility guard & docstring message should suffice. Deprecation warnings would annoy consumers of API who want to keep compatibility with really old config file locations. In the worst case they will simply have to remove those few lines when they port to KF6 :)

Maybe we should add a new constructor + from method that takes a flags enum with permitted "plugin file formats"?

Done with https://invent.kde.org/network/konversation/-/merge_requests/61#note_366174

This should take care of the plasma-frameworks dependency: https://invent.kde.org/frameworks/krunner/-/merge_requests/83

krunner (links against plasma-framework)

But I am still not sure if we even need the Event baseclass then. All the individual events could extend from QEvent and then provide a static test method.

KTorrent also uses those plugins, https://invent.kde.org/network/ktorrent/-/merge_requests/53 cleans that up

But that would mean for the dataengines, that we have to load two incompatible plugin types which are supposed to do the same.
If we only require some build system changes to move the plugins to a new lib I don't think it is worth doing it during KF5.

@ahmadsamir @kossebau What do you think, is the direction it goes in good?

My draft branch is https://invent.kde.org/frameworks/extra-cmake-modules/-/commits/work/deprecation_level_setter_utils

Doesn't Plasma also use the inhibition stuff? not sure if it's from Solid or somewhere else.