Create Task
Maniphest T15742

Get rid of QueryMatch::Type::InformationalMatch
Open, Needs TriagePublic
Actions

Description

This enum value is quite ugly from an API POV, because we mix the sorting of KRunner with the special behavior when the match is run.
For the special behavior we already have https://invent.kde.org/frameworks/krunner/-/blob/master/src/runnercontext.h#L244 as an alternative. This was needed to implement the help runner.

What makes the deprecation difficult is that we do not have this alternative for DBus runners and I do not know if third party runners use this feature. Also, deprecation warnings could be emitted on the Krunner side, but third party developers that work on their runner in python might not catch the warnings.
An alternative might be to add a separate key to the property map for the query that should be put in KRunner. However, I am not comfortable with introducing API if we do not even know if it has a usecase. Of course we could add it only when sb. complains :D

Do you have any better ideas?

Related Objects
Search...

alex created this task.Aug 12 2022, 1:26 PM
alex added a comment.Sep 1 2022, 7:34 AM

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.

What makes the deprecation difficult is that we do not have this alternative for DBus runners and I do not know if third party runners use this feature

After some debugging, this feature does not work as expected. This is because QueryMatch::data is in case of DBus runners a QVariantMap , meaning the toString call on the QVariant will return en empty string. Thus we do not support the special behavior. See https://invent.kde.org/frameworks/krunner/-/blob/master/src/runnermanager.cpp#L765