[Feature Proposal] Minimal alternative character input system (Gboard-style) for multilingual typing

Brainstorm
1

Hi all,

I’d like to propose a simple and minimal desktop feature (or standalone application) that could significantly improve the typing experience for people who frequently work with multiple languages, transliteration, or extended diacritics — such as translators, writers, academics, or language learners.

:wrench: The problem

Typing special characters or accented letters on a Linux desktop is often inefficient and distracting:

  • Users must memorize Compose key sequences,
  • Switch keyboard layouts,
  • Or copy symbols from external tools/websites.

This disrupts writing flow and breaks concentration — especially for people working across multiple languages or writing complex texts.

:light_bulb: The inspiration

On mobile keyboards like Gboard, you can long-press a key to access all variants of a letter (e.g. á, à, â, ä, etc.). It’s fast and intuitive — but there’s no equivalent on desktop systems, particularly under KDE.

:white_check_mark: The proposal

(‘ALT’ not ‘CTRL’)

file_000000003ce061f4b7080dc66b5c1c4b
file_000000003ce061f4b7080dc66b5c1c4b1024×1024 130 KB

I propose a lightweight tool (not a full input method framework) that brings a similar idea to the desktop with the following behavior:

  • Hold Alt and press a key, for example Alt + A → inserts á.
  • Press it again (Alt + A, Alt + A…) to cycle through more variants: à, â, ä, ã, etc.
  • A small translucent overlay in the corner of the screen shows available variants and the currently selected one — nothing intrusive or interactive, just informative.
  • Character mappings (per key) could be defined via a simple JSON config file.
  • Works globally across the system, without switching layouts or needing Compose sequences.

:desktop_computer: Goals and scope

  • Minimal, non-intrusive user experience
  • Works on X11 (Wayland support could come later)
  • Qt-based overlay UI, optionally system tray icon for configuration
  • Zero-dependency on full input method frameworks (like ibus, fcitx, etc.)
  • Keeps focus on typing, not setup or configuration

:puzzle_piece: Example use case

Keystroke Output
Alt + A (1x) á
Alt + A (2x) à
Alt + A (3x) â
Alt + A (4x) ä
Alt + A (5x) ã
Alt + A (6x) cycles back to á

:thinking: Why this could be useful

  • Makes typing multilingual or technical content fast and seamless
  • Greatly improves ergonomics for writers, translators, and linguists
  • Offers mobile-like smart input on desktop without bloat
  • Keeps everything keyboard-driven — no GUI popups to interact with

:red_question_mark: Questions for the KDE community

  • Has something similar ever been proposed or prototyped?

  • Would this be better suited as:

    • a standalone helper application?
    • an optional input layer/plugin for Plasma?
    • a keyboard layout enhancement or Plasma widget?

  • Could this be useful to integrate with existing KDE input frameworks?

I believe the idea is simple but could make a big difference in real-world typing comfort, especially for users dealing with language variation daily.

If there’s interest, I’d be happy to start working on a prototype, or collaborate with anyone interested in shaping the idea further.

Thanks for reading!

4 Likes
2

Hi @BlackSparrow, thanks for this excellent write-up! I like the user interaction design that you’re proposing. I’m even happier to see your offer of actually working on code for this. Let me get right to your section about :red_question_mark: Questions for the KDE community.

Has something similar ever been proposed or prototyped?

Yes! In 2023, David Edmundson published a blog post titled “New ideas using Wayland Input Methods”. This was in fact backed by actual, working code which David which he uploaded on KDE Invent as inputmethod-playground. The repository includes all the input methods mentioned in the blog post, plus some common code shared by all of them. The one that you’d be interested in is described in the blog as “Direct Diacritic Display”.

As you may guess, this uses a different approach than the “Works on X11 (Wayland support could come later)” approach you suggested. On a technical level, X11 and Wayland work very differently in terms of input methods.

If supporting both X11 and Wayland is an explicit goal for you, it’s probably a better idea to implement this as part of an input method framework such as ibus or fcitx. These frameworks have invested a lot of effort to integrate with different platforms and toolkits. Heck, there might already be an input method engine for one or both of these that handles diacritics, I haven’t checked.

Personally though (and I think I can speak for most of the relevant KDE developers here), I would suggest removing X11 from the scope, in return for a much more compact codebase. KDE statistics have previously shown that 80% of Plasma 6 users have switched to Wayland, that was about a year ago so this percentage has probably increased since then.

Would this be better suited as:

  • a standalone helper application?
  • an optional input layer/plugin for Plasma?
  • a keyboard layout enhancement or Plasma widget?

I think David is on the exact right track here that this is best implemented as an input method, which on Wayland would use the official input-method protocol. There’s a little snag in that KWin supports input-method-v1, wlroots-based compositors support the less capable input-method-v2, and input-method-v3 which will hopefully bring about a common consensus is still in the works, and GNOME hardcodes ibus anyway. So for Plasma-focused things, we stick with input-method-v1 until further notice.

Could this be useful to integrate with existing KDE input frameworks?

The nice thing about using input method APIs is that they already integrate, not just with Qt/KDE apps, but also with other toolkits that make use of common text input APIs. The saving grace on Wayland is that even though desktops haven’t been able to agree on the best and only input-method protocol yet, all of them support the text-input-v3 protocol which is what actually matters to applications.

As a developer, I encourage you to try out David’s prototype and see how far it is from something that you’d like to use on a daily basis. If we can get even one of these input methods performing well enough that it can be shipped with Plasma by default, that would be a major win for KDE.

If you have further questions, feel free to ask here (I’ll do my best to find useful answers for you) or on Matrix, #kde-input:kde.org where we talk about all kinds of input stuff or #kwin:kde.org where support for Wayland protocols and input plumbing is implemented in practice. You can find me there as jpetso.

4 Likes