Right now, Plasma has an emoji picker, that is a purely standalone tool that requires user copy-paste to use it and has no integration with the system, which makes it not very convenient to use. Current available way of typing emoji: 1. In-app support This is commonly seen within chat application, e.g. telegram, neochat, nheko, or web pages (even including this gitlab page :) ). They may also convert emoji character to its internal sticker system. Usually available as either "emoji code" that is leading with ":", or a selector button in the chat box. {width=1029 height=268} 2. Toolkit support This is similar to (1), but on a border scope. Currently, gtk 3+ has built-in support for it. {width=499 height=448} 3. By input method framework (physical keyboard based) Both fcitx and ibus supports them, but implemented differently. ibus one is actually pretty unusable on wayland, due to the fact that it is implemented as a differnt Gtk window while zwp_input_method allows only one popup surface, and it is tightly coupled with ibus's gtk UI. Fcitx implements emoji in multiple different way as a engine agnostic feature and uses fcitx's standard candidate window: {width=346 height=99} (Use fcitx's [quickphrase](https://fcitx-im.org/wiki/QuickPhrase) to search emoji, data is from unicode cldr annotation and based on current input method language but always fallback to English) Quick phrase in fcitx also provide built-in ":" leading matching like (1) {width=606 height=78} 4. By input method engine Many input method engine, choose to implement their own Emoji logic, so user can type text mixed with their language and emoji characters. In such case, engine may also try to remember the user input and predict better next time. {width=363 height=62} (Result from fcitx's pinyin engine, ibus's pinyin can also do similar thing) {width=231 height=303} (Result from mozc engine https://github.com/google/mozc/) 5. By input method (via virtual keyboard) This is similar to (3) (4), but usually presented in a different way in virtual keyboard. Remember, you might not be able to "search" easily in virtual keyboard since virtual keyboard is already displaying the emoji page, this may require quite some UI consideration if you want to implement search. Commonly they are implemented as a page within the on-screen keyboard, examples can be found easily on mobile phone. {width=300} Fcitx's emoji page on android {width=300} Gboard's emoji page on android. Current issue: While we have plasma emoji picker, we could hardly say it integration in any of (1-5) method, which leave it in a undesirable state. We want to make a better use of it to support emoji typing on Plasma. And the approaches (1-5) all have different technical implications on how it can be implemented. Followings are some of my opinions on different approach and possible way to implement them. 1. In-app opt-in feature The picker can be provided as a kirigami widget, that to be used as an addition to any qml based text box (not sure about qwidgets, but I think it's also do-able though it may pull in qml to non-qml app). 2. Implement at toolkit level a. Implemented as a part platform plugin, so it can be used in any Qt based applications runs on KDE. b. chain it with QPlatformInputContext, so it goes with Qt's input method handling. Either option will create an QWindow which is not managed by the application code, which may be too invasive and breaks application logic. Also it won't support non Qt-toolkit, or self-compiled app bundled Qt. Not possible to implement on random toolkit, like winit or xlib, or SDL. 3. Make emoji picker a standalone input method (engine) and integrate it like other input method engine. It would requires user to add it as an input method the keyboard configuration. User may need to switch back and forth between multiple engines, since emoji picker as an engine, will not be capable to type languages but just emoji characters. 4. Make emoji picker an input method-"like" process, but is a new addition to current kwin's input method architecture. In this approach, we make emoji picker a "temporary" input method and give the input method connection back to the regular one once emoji picker has done it's work. Right now, kwin assumes there is only one input method process, this requires kwin to keep multiple input method process around and manage which one is the active one. Also, to avoid the abuse of such protocol, kwin may need some new configuration, together with some new hint other than "X-KDE-virtualkeyboard" to indicate this type of process is allowed to use such wayland protocol extension. For emoji picker case, this can be called something like "input-helper" which allows to temporary grab away keyboard from input method's existing grab. I feel this might also be an opportunity to fit handwriting or speech recognition processes into this new "input-helper" category, the features implemented with input helper can act like an light "overlay" on top of regular input method.