Change Details

Currently all of the classes are part of the "Plasma" namespace. This is due to it being part of plasma-frameworks during the KDE4 era. However KRunner does not have anything to do with plasma-frameworks, except one deprecated and defunct method. Moving the classes out of the namespace will cause source code incompatibilities. But by adding `using namespace Plasma` to our runners, we could already do the necessary changes to our runners now. One could add such statement to the `AbstractRunner` header in a negated deprecation guard ``` #if !KRUNNER_ENABLE_DEPRECATED_SINCE(5, 91) using namespace Plasma; #endif ``` This way consumers don't need to add the statement themselves and clean it up after the KF6 port. With the deprecation guard we do not change the behavior of the header unless consumers increase their deprecation version. Based on my experience one rarely uses KRunner and plasma-frameworks in combination, which is why the `using namespace` statement should not cause issues.

Currently all of the classes are part of the "Plasma" namespace. This is due to it being part of plasma-frameworks during the KDE4 era. However KRunner does not have anything to do with plasma-frameworks, except one deprecated and defunct method. Moving the classes out of the namespace will cause source code incompatibilities. But by adding `using namespace Plasma` to our runners, we could already do the necessary changes to our runners now. One could add such statement to the `AbstractRunner` header in a negated deprecation guard ``` +#if !KRUNNER_ENABLE_DEPRECATED_SINCE(5, 91) using AbstractRunner = Plasma::AbstractRunner; #endif ``` This way consumers don't need to add the statement themselves and clean it up after the KF6 port. With the deprecation guard we do not change the behavior of the header unless consumers increase their deprecation version. Based on my experience one rarely uses KRunner and plasma-frameworks in combination, which is why the `using namespace` statement should not cause issues.

Currently all of the classes are part of the "Plasma" namespace. This is due to it being part of plasma-frameworks during the KDE4 era. However KRunner does not have anything to do with plasma-frameworks, except one deprecated and defunct method. Moving the classes out of the namespace will cause source code incompatibilities. But by adding `using namespace Plasma` to our runners, we could already do the necessary changes to our runners now. One could add such statement to the `AbstractRunner` header in a negated deprecation guard ``` +#if !KRUNNER_ENABLE_DEPRECATED_SINCE(5, 91) using namespaceAbstractRunner = Plasma;a::AbstractRunner; #endif ``` This way consumers don't need to add the statement themselves and clean it up after the KF6 port. With the deprecation guard we do not change the behavior of the header unless consumers increase their deprecation version. Based on my experience one rarely uses KRunner and plasma-frameworks in combination, which is why the `using namespace` statement should not cause issues.