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

Reply via email to