Future of KDE Connect

[Aleix Pol]

On Tue, Jan 6, 2026 at 4:49 PM Michael Tiernan
<michael.tiernan at gmail.com> wrote:
>
> Knowing that this isn't the best forum for it I'll apologize if it is too far out of the remit for this list. I offer these thoughts in the hopes of sharing and fostering new/ideas/features.
> No expectations, just trying to be helpful.
>
> A "suggestion" (or random neurons having a drunken tango lesson) would be that there may be an opportunity to split the design so that the "front" is separated from the middle "do the 'action'" separate from the "back" or transport part of the process which may allow or encourage others to expand from direct connect to maybe include indirect connect across non local networks.
> A grumble I've always had but never formalized (until now) is that I think it would be helpful if the settings could be saved in a transportable format (XML/yaml/json/etc.) to then load on another machine. Separating the "kde connect" part from the "actions" would help.

What makes xml more portable than the rc files we put in .config?

> Someone out there must be clever enough to figure out how to create a reasonably consistent interface for it that permits something like a CLI action for some things.

What do you miss from kdeconnect-cli?

> As part of all that, *maybe* it would be an option to permit queuing messages/commands/responses between connections.

It has pros and cons. Probably it needs to be done per-feature rather
than a transparent queue. Queuing an URL sent makes sense. Queuing
media player commands or clipboard events not so much.

Best,
Aleix