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.
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
(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 !
(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.