All cleaned up in master now :)

We have in KNSWidgets an Action class, which internally takes care of the KNS logic.
The standard action stuff has been removed for master.

All of this has been cleaned up with the removal of deprecated API

https://invent.kde.org/frameworks/krunner/-/commit/e7fcbe6dde6aaa57a15a6029da373cfed6d65fd0

where the type id was generated with the shell command
printf "0x%08X\n" $(shuf -i0-4294967295 -n 1)
(though it will give you a different number if you try) :-)

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

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/304 removes the internal leftovers

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

https://invent.kde.org/frameworks/knewstuff/-/merge_requests/223

https://invent.kde.org/frameworks/knewstuff/-/merge_requests/223

https://invent.kde.org/frameworks/knewstuff/-/merge_requests/223

Considering that KMoreTools and KNS have only the idea in common that you get additional software, I think having separate repositories makes the most sense.

https://invent.kde.org/frameworks/knewstuff/-/merge_requests/222

Right, so this is kind of hiding a further big one - we essentially want to split KNewStuff into four: KNewStuffCore, KNewStuffWidgets (which is what's currently called KNewStuff3), KNewStuffQuick (the Qt Quick components), and KMoreTools.

I will take care of this and do some planned refactorings

This will be resolved with the KF6 changes that move the class

Done with https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/142 and https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/74

I agree with this not being ideal. Perhaps we could settle for supporting an URL in the json? Then that could point to the OCS page or a local file, in which case there are little privacy concerns.

You have ported plasma-settings, that seems to have been the last usage.

Hacking the ECMAddTests to also link PRIVATEly PUBLICly fixes the issue

With the deprecation of KDecalrative::setupEngine, this class is consequently deprecated

Done with https://invent.kde.org/frameworks/krunner/-/merge_requests/107

Sieht gut aus 👍

As discussed with Kai, having a match as text-only without a run-functionality makes sense. But for that we already have the QueryMatch::isEnabled which we already support.

In KScreenLocker was a usage introduced that I got rid of using https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/92.

kdeclarative/ everything that calls KDeclarative::setupEngine

I now need to take care of the migration code and remove the code from Kate

As far as I can see, the API allows one to reuse the engines

The MR landed and all providers inside of Plasma have been ported.

There was one leftover hidden in kactivitymanagerd: Taken care of with https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/26

There is org.kde.krunner interface which could be used instead but it requires passing

Since there is nothing on the Plasma side to do and it only waits for KF6 branching, I have adjusted the tags accordingly

https://invent.kde.org/frameworks/kcmutils/-/merge_requests/84 landed and is used n two Plasma KCMS, the next step is de-duplicating the about plugin stuff

Since we have a few frameworks releases, the version numbers should get bumped:

With the package structures being cleaned up, this task is now resolved.

https://invent.kde.org/plasma/powerdevil/-/merge_requests/92

I realized that the logic @iasensio referred to was completely broken in it's current form in KRunner. https://invent.kde.org/frameworks/krunner/-/merge_requests/102/ addresses this.

As discussed in the weekly, this should be done now, because the QML port is unlikely to make it in time for Plasma6.

plasma-framework: 6 failures (3 also fail with Qt5)

i have done the porting while noch changing the keys. generally speaking, we should have a discussion about the prefixes in KF6, since other frameworks are also affected.

plasma-sdk: two issues remaining (use of Theme::pluginInfo and Applet::loadPlasmoid)

Used for folder preview plugins

systemsettings: only KServiceTypeTrader remaining

Only some cleanups in the json files, will take care of that in the next week.

https://invent.kde.org/frameworks/krunner/-/merge_requests/97 is a draft of mine. Though I am not sure if we want to keep the X-KDE-PluginInfo prefix when reading the author information. IMHO it is rather ugly and represents a terminology we no longer have with us getting rid of KPluginInfo.

For reference https://invent.kde.org/plasma/kwin/-/merge_requests/2212

the macro is of course a bit opiniated and I am not sure if we even want to have it during all of KF6 just to ease the transition period a bit. If we use KPluginFactory, we could simply do:

#if KF6_BUILD
K_PLUGIN_CLASS_WITH_JSON(MyClass, "bla.json")
#else
code that is currently around
#endif

Unlike other plugin systems, we want to keep the desktop files compatible for KF6.

but we need to do that anyway to get rid of KServiceTypeTrader

It nevertheless is a 6 blocker though, no?

This was fixed by me a few plasma versions ago

https://invent.kde.org/documentation/develop-kde-org/-/merge_requests/166 took care of updating the docs

https://invent.kde.org/frameworks/knewstuff/-/merge_requests/157

https://invent.kde.org/frameworks/knewstuff/-/commit/09ee877e55e57159ef3d3096097763952ee9b62e
https://invent.kde.org/frameworks/knewstuff/-/commit/9b60861869481ebc5f6205005bda8a640cd3b178
https://invent.kde.org/frameworks/knewstuff/-/commit/15a302d2b338edeab50ac1ee95b1da564c056e16

Elisa and latte-dock still need the same change, however they are not part of the Plasma release cycle.

https://invent.kde.org/plasma/kwin/-/commit/504e0e01ccd196de367f77c4211e1ccc4e8f01af
https://invent.kde.org/plasma/kscreenlocker/commit/9ec761e6d1524df940316227b2c18eb9e080ee81
https://invent.kde.org/plasma/kde-cli-tools/-/commit/8415c2be7fd8d8e4e7fec7f1751f833e676d9d78
https://invent.kde.org/plasma/discover/commit/67909e7a1113b7650056c02246c7b475e5d4f58b
https://invent.kde.org/plasma/plasma-sdk/commit/0e751f7b4901349b7a05b143df17c2b86227009b
https://invent.kde.org/plasma/plasma-systemmonitor/commit/920acfb4f32dd64e5756c74a4f5bfe366073bcc5
https://invent.kde.org/plasma/systemsettings/commit/6ecd2a53a78625689554896568c755e697fc96b4
https://invent.kde.org/plasma/plasma-workspace/commit/b68b59dac6f4b70acb56587dc74e3f121f72bc2e
https://invent.kde.org/plasma/plasma-desktop/commit/4510ecb32cbeb8a875ba7de2a97ad9e603a893b2

I will try to create a model for the query logic, this can then be used from QML & the KRunner plugin. Ideally the model can be reused for the kate profiles.

Personally, I would prefer a window. Another argument for this is that for the config we need a window anyways. Meaning it would be consistent.