Bug 505171

Summary:	[Feature Request] Allow krunner plugins to render QML
Product:	[Plasma] krunner	Reporter:	Luna <kde.lunalina>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	alexander.lohnau, natalie_clarius, nate
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Luna 2025-06-03 15:04:06 UTC

SUMMARY

After using plasma for years, krunner has become my most powerful tool, and the primary way I interact with my system. While very powerful, I now see it's shortcomings. For example, when you need to render a lot of small elements, say emojis, your only solution is to display them as a list, which is very unpractical. That's why I would like plugins to be able to render their own QML windows inside krunner itself, similar to what Raycast is doing over on macOS, or what the new powertoys command palette on Windows.

The ideal, *for me*, would be to be able to just search for "emoji smile" and have krunner render on the right a small grid of all matching emojis, and a little description of the emoji under it. What gets rendered on the side would be defined by the plugin itself.

Another example would be file search plugin, it could render a small dolphin view with quick actions.

Comment 1 Nate Graham 2025-06-03 23:18:05 UTC

Thanks for the idea, and I'm glad KRunner has been useful for you! However arbitrary QML is not going to happen, sorry. This would represent a permanent source of bugs and an attack vector for malware. It's something we've seen over and over again with QML-based 3rd-party  content, which is why we're moving away from it for everything except actual widgets, which we plan to eventually constrain in a sandbox.

There may be other ways to achieve what you want if we focus on the issues themselves rather than jumping all the way to proposing a solution.

See also https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution

Comment 2 Luna 2025-06-10 09:13:04 UTC

(In reply to Nate Graham from comment #1)
> Thanks for the idea, and I'm glad KRunner has been useful for you! However
> arbitrary QML is not going to happen, sorry. This would represent a
> permanent source of bugs and an attack vector for malware. It's something
> we've seen over and over again with QML-based 3rd-party  content, which is
> why we're moving away from it for everything except actual widgets, which we
> plan to eventually constrain in a sandbox.
> 
> There may be other ways to achieve what you want if we focus on the issues
> themselves rather than jumping all the way to proposing a solution.
> 
> See also
> https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution

Hello, I can see how QML would allow for another attack vector, however, as far as I can understand, actual Krunner plugins can already be malicious if wanted, so that would not make the issue much worse, and I assume the same sandbox logic could also be applied to them.

> There may be other ways to achieve what you want if we focus on the issues
> themselves rather than jumping all the way to proposing a solution.
> See also
> https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution

Am sorry, I had read that article, but since what I am asking is a *feature*, and not a bug, I thought it was not really applicable here. My mistake.

The point I am trying to make, is I would like plugins to be able to render whatever UI they want inside Krunner itself. 

Thank you for your understanding and time !

Comment 3 Nate Graham 2025-06-10 14:12:21 UTC

(In reply to Luna from comment #2)
> The point I am trying to make, is I would like plugins to be able to render
> whatever UI they want inside Krunner itself. 
I get that. It's just that history suggests this isn't a good idea.