Move krunner also to plasma bundle?

[Alexander Lohnau]

Heyho,

I discussed with David Edmundson that it might be a good idea to move
the milou QML bits to plasma-workspace. That allows easier codesharing
for some KFileItemActions integrations that Kai (and I in an abandoned
patch) have been working on. Though, this has the same issues regarding
the KWin overview effect.

Regarding Friedrichs points:
In KF5, KRunner has had a large dependency tree, including
plasma-frameworks in its public header. The model has been moved from
Milou to KRunner in KF6. This makes KRunner more useful (without having
to implement a model oneself) for consumers. Due to the model move,
there should no longer be many issues of synchronizing changes, because
logic like sorting is now in one place.

I do not think that is it makes sense to differentiate between stable
plugin APIs and other, unstable APIs. Maybe one non-plugin relevant API
is the model, but that only exposes stuff from the plugin API (like
QueryMatch properties).

Regards
Alex

On 11/5/23 18:17, Nate Graham wrote:
> On 11/5/23 10:12, Nate Graham wrote:> +1, it's an integral part of
> Plasma and I would support moving it there.
>> And Milou is already there. For that matter, I'd also support moving
>> both Milou and what's currently in the KRunner framework just into
>> plasma-workspace for simplicity since it's a required dependency anyway.
>>
>> Nate
>
> ...Though on second thought, putting it in plasma-workspace would
> probably not be ideal since then it would be harder to use KWin (which
> embeds KRunner in the Overview effect) without Plasma. So maybe a
> separate repo in Plasma would be better. Heck, maybe we could merge
> the KRunner framework into the Milou repo and rename it have a name
> that's at least tangentially related to its content. :)
>
> Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20231105/dd29628e/attachment.htm>