[ANNOUNCE] kwin-type v0.1 is released

[Jason A. Donenfeld]

Hi again,

On Mon, Oct 26, 2026 at 10:48 PM David Edmundson
<david at davidedmundson.co.uk> wrote:
>
> On Mon, Oct 26, 2026 at 3:24 PM Jason A. Donenfeld <jdonenfeld at kde.org> wrote:
> >
> > Hi Vlad,
> >
> > On Mon, Oct 26, 2026 at 02:23:39PM +0000, Vlad Zahorodnii wrote:
> > > > Some background: I didn't want to have to make such a utility, but all
> > > > the existing utilities for this seemed deficient in one way or another
> > > > -- requiring /dev/uinput or requiring virtual-keyboard-unstable-v1 or
> > > > using portals + EIS. I actually initially made a utility that used
> > >
> > > It's still highly advised that you look for supporting libei. We want to
> > > remove the fake input protocol in favor of supporting only libei.
> >
> > Nooooeeeee.... libportal + libei is really stinky. There's gobs of dbus
> > setup and it's way slower and has more overhead.
>
>
>
> > And then every time you
> > use it, you have to authorize the caller. So then there's a need for a
> > `--token-file=...` parameter and logic to automatically replace that and
> > also lock it properly against concurrent use.
>
> There is a path for libei without portals. It might be a happy medium
> between avoiding your portal woes and using the API we will support
> long term.
>
> > I went down this route, fully implemented it, thought it was disgusting,
>
> >and org_kde_kwin_keystate to deal
> with capslock being potentially enabled.
>
> libei supports sending the entire text string directly. This is
> stronger than your current algorithm.

Alright, after trying it out, I'm basically satisfied with this
solution. Thank you for pointing me toward it:

https://git.zx2c4.com/kwin-type/tree/kwin-type.c

The diff from before is -183/+108! Pretty nice.

This is still KDE-specific, of course. Will the virtual keyboard move
over to org.kde.KWin.EIS.RemoteDesktop also?

Jason