7 ms·

Emotional about X11: I'm creating a pure X11 “emoji keyboard”

131 points by Zirias 2y ago

simon_acca 2y ago
Nice project! Made me think of the emoji physical keyboard from Tom Scott https://youtu.be/3AtBE9BOvvk https://youtu.be/3AtBE9BOvvk
deleted 2y ago
[deleted]
Zirias 2y ago
In case someone wonders what's "special" about it: user perspective: As far as I know, it's the only tool offering somewhat reliable emoji input using faked X11 keyboard events. "x11-emoji-picker" comes close, but delegates faking events to "xdotool", with weird consequences like having to restart it to direct emojis to a different window ;) hacker perspective: It directly integrates xcb in a different event loop (here based on pselect()) and actually works – xcb is IMHO pretty great except for pretty much enforcing its own async model, internally using poll() and reading from the X server into buffers at many occassions, hidden from the consumer. If all your app does is communicate with the X server, you just happily use xcb's model. As soon as you need different things (e.g. local timers), you have a problem. The typical way to address that is dedicating another thread to xcb (AFAIK also done that way by toolkits offering an X11 backend). I hated that idea enough to be stubborn about doing it directly in my main thread, and with quite some trial-and-error, finally succeeded.
- 1oooqooq 2y ago
  why not use xcompose?
  - Zirias 2y ago
    Not sure you really mean the compose mechanism provided by Xlib (and xkbcommon etc ...)? If so, this wouldn't work for all these emojis that are represented by grapheme clusters, ZWJ-sequences or are just "qualified". The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint. Even for those emojis consisting of a singe codepoint, it would really miss the point. There are LOTS of emojis available, an emoji keyboard (or emoji picker) shows them organized in groups and allows searching for them.
    - 1oooqooq 2y ago
      i enter the five emojis i ever need to use by pressing <multikey>+u and then typing the emoji word. i think i can use skin color thumbs up just fine. but yeah, no search. but also no extra windows. when i asked i assumed compose + something like an IME could solve both with the search/window being optional.
      - Zirias 2y ago
        Xcompose only offers sequences started with the "compose" key (whatever it is mapped to) and resulting in a single X key-symbol, so to type an emoji needing multiple uniciode codepoints that way, you'd have to enter multiple "compose sequences". Whatever you describe here is not simple Xcompose. AFAIK, GTK offers entering unicode codepoints in a similar way ... Of course you can do a lot of things with "input methods" (like popping up some "picker" only when wanted). But then you'll depend on X clients being aware of them in some way, e.g. by implementing the XIM protocol. Lots of applications have that (even xterm), so it might be what you prefer and that's fine. My method with faked key press events is definitely hacky, but will work with any X client, that's the point of it ;)
        numpad0 2y ago
        Are there any major apps that don't support XIM? An IME is required for CJK languages, so there shouldn't be apps that meet (in common use && have CJK users && not supporting IME) criteria. Implementation is beyond my ability, but if en-US locale were to finally adopt IME, I think it should be semi-trivial to include an optional dictionary file trained with emoji :tofu_on_fire: notation.
        kps 2y ago
        > Xcompose only offers sequences started with the "compose" key (whatever it is mapped to) Not correct. For example, on my usual keyboard layouts¹, I use sequences starting with <dead_A> and <dead_U> for superscripts and subscripts. > and resulting in a single X key-symbol Also not correct. I certainly have a few non-single-keysim entries in my .Xcompose, e.g. <Multi_key> <R> <2> ↦ ℝ². ¹ https://github.com/datatravelandexperiments/kps-keyboard-layouts https://github.com/datatravelandexperiments/kps-keyboard-lay...
  - kragen 2y ago
    i do love me some xcompose (https://github.com/kragen/xcompose https://github.com/kragen/xcompose) but being able to see the possible options is pretty nice
    - deleted 2y ago
      [deleted]
- deleted 2y ago
  [deleted]
elflaune 2y ago
as long as i need to run nvidia with multiple monitors, i'll hang on to x11.
- spupy 2y ago
  Is there an issue with Wayland for your setup? I run Gnome + Wayland on Fedora, with two monitors with different sizes and different refresh rates - eerything seems to run pretty fine, including gaming?
  - cheeseomlit 2y ago
    Not OP but the last time I tried Wayland was about a year ago (also on Fedora) and I had similar issues using multiple monitors with different refresh rates, ended up switching to x11 which resolved it (using an nvidia card with nonfree drivers if that matters). But it seems I'll have to give Wayland another try if they've addressed it since then, I hadn't been keeping up with it.
- cies 2y ago
  We're in 2024Q3, things have improved. Nvidia helped out. (X)Wayland/KDE/Qt/GNOME bugs were fixed. Apart from that, use X11 as long as you wish! I'm just glad we can finally improve the open source desktop-environment infrastructure to match those of Windows and macOS: we've been stuck for too long.
  - LeeCyriaca 2y ago
    X11 was and still is superior to wayland
    - WD-42 2y ago
      My tearing-free window movement begs to differ
      - Longhanks 2y ago
3np 2y ago
Looks promising! I think I did managed to wrangle fcitx into some reasonable emoji input in the past but at some point it broke / I lost it and configuring that tool is just an unpredictable mess... Will keep an eye on yours!
- Zirias 2y ago
  Using input methods is the "technically best" solution of course, but it needs configuration and some application support, therefore I wanted something working with "plain X" :) Sending fake key events is unfortunately "hacky". You need to temporarily switch the keyboard mapping, and many X applications have races between applying a new mapping and processing key press events, that's why I added (now configurable, new release soon) delays... and also, I found applications (e.g. chromium) having issues to correctly combine ZWJ sequences from individual key events, so I added more "hacks" to help with that, also just made configurable. To sidestep these issues, my tool also offers transfer via "primary selection": Just middle-click an emoji to select it, and middle-click again where you want to insert it. Downside: Two clicks instead of just one.
fao_ 2y ago
> As far as I know, it's the only tool offering somewhat reliable emoji input using faked X11 keyboard events. A few years ago I wrote https://gitlab.com/finnoleary/zhmenu https://gitlab.com/finnoleary/zhmenu (excuse the deadname in the URL there). I'm reasonably sure it partially counts? I'd meant to build an emoji database for it but never got around to it.
deleted 2y ago
[deleted]
dark-star 2y ago
Writing a pure X11 application in 2024 is an interesting choice, given the recent push to Wayland. Nevertheless, it looks like a pretty cool tool!
- destructionator 2y ago
  The recent push to Wayland in 2024 is an interesting choice, given how productive and usable X11 is.
  - Zambyte 2y ago
    I'm very glad people made the push! My configuration has been much nicer being based on Wayland for the last 4 years or so than it was on X. Screentearing and limited refresh rates on mixed Hz setups are now a thing of the past :)
  - WD-42 2y ago
    Have fun yelling at that cloud for the rest of time.
  - talldayo 2y ago
    x11 is depreciated. It has no active maintainers and barely even qualifies for "maintenance mode" status; the push to remove Xorg can be justified by enumerating the security issues and nothing else. Strictly speaking Linux is "productive and usable" with nothing but a terminal multiplexer and a shell to work with. With expectations as high as they are in 2024, I don't think former Windows or Mac users will feel at-home with an x11 session. Switching away from bazaar-style software development is a prerequisite for the Year of the Linux Desktop.
    - mouse_ 2y ago
      I really do like Gnome and Wayland. I use them every day. That being said, Bazaar-style software development is the sole advantage free desktop has over macOS and Windows.
      - 2y ago
amelius 2y ago
Unicode sucks. There is a glyph for a hammer, for a screwdriver, but not a soldering iron. During COVID, people were using a golf club as a substitute for a cotton swab. We now have generative AI that can make any desired emoticon you can dream of, except you can't use it because of Unicode.
- Y_Y 2y ago
  Ya let's integrate gpu-accelerated emoji generation into unicode and require it everwhere, we can call it UTF-8B and standardize on 8GiB per character until that turns out not to be enough.
  - account42 2y ago
    UTF-8 is innocent here, it's just a (very clever and useful) encoding of Unicode. The problem is adding junk codepoints based on current political ideology, not how they are encoded.
    - toast0 2y ago
      If you use a consortium governed character set, you get the problems of government by consortium. Probably still better to have a versioned universal set than so many to choose from.
    - Y_Y 2y ago
      For the record, I like utf8, I was just being silly.
    - Zardoz84 2y ago
      > junk codepoints based on current political ideology What do you mean ?
      - jandrese 2y ago
        Maybe ability to turn skin color brown? Or maybe the poster is mad that some country flag was or wasn't included? The only other distant possibility is how some character sets turn the gun emoji into a water pistol, but that's not on the Unicode consortium. I can't think of anything else that is political in the set.
yoavm 2y ago
I just have this one liner for Wayland: cat ~/.local/share/emojis/emojis| wofi -i -d -M fuzzy -H 700 | cut -d " " -f 1 | tr -d '\040\011\012\015' | wtype - It shows an overlay fuzzy-searchable list of all emojis, and it writes selected one to the input regardless of the toolkit. assign it to a keyboard shortcut and you're good to go. the ~/.local/share/emojis/emojis file is just a list of all emojis: cat ~/.local/share/emojis/emojis | head -n 3 Grinning Face Grinning Face with Big Eyes Grinning Face with Smiling Eyes (HN is removing the emojis but each line starts with the emoji self, followed by the description)
- Zirias 2y ago
  Note input is "out of scope" for wayland and XKB is used there for keyboard input as well. I just had a quick glance at "wtype" source and indeed, it fiddles with the keymap, using xkbcommon. So, assuming a suitable X11 replacement for this "wofi" tool, you could do exactly the same on X11 using "xdotool".
  - yoavm 2y ago
    Indeed nothing special about Wayland for this, I have used `xdotool` in the old X11 days.
- Y_Y 2y ago
  And where can one obtain this `emojis` file?
  - quotemstr 2y ago
    You know, we should add an emojis dictionary to http://wordlist.aspell.net/ http://wordlist.aspell.net/ for exactly this purpose. Why not have a /usr/share/dict/emoji just like we have /usr/share/dict/words?
  - yoavm 2y ago
    here it is: https://gist.github.com/bjesus/4b447dcb8a272f4c795b78752acec75f https://gist.github.com/bjesus/4b447dcb8a272f4c795b78752acec...
freedomben 2y ago
Fun project, thanks for sharing! On Gnome there is the "Characters" application which is pretty handy. I do want to make a few improvement to search, but otherwise it's pretty good. You copy the unicode character to the clipboard and can then paste it wherever you need. If you run Gnome it's probably already installed. If not: https://gitlab.gnome.org/GNOME/gnome-characters https://gitlab.gnome.org/GNOME/gnome-characters
- seltzered_ 2y ago
  There's also a gnome-based app called Smile: https://github.com/mijorus/smile https://github.com/mijorus/smile
  - freedomben 2y ago
    Neat, thanks for sharing! This just replaced "Characters" for me. Seems really well done, and most importantly the search works well and it has "recents". I do wish it wouldn't automatically close itself after clicking/copying an emoji, but I try not to let perfect be the enemy of good :-)
- Zardoz84 2y ago
  KDE/Plasma comes with a Emoji selector. It usually can be launched with Super+.
jandrese 2y ago
This is a cool project, but hard to show off since HN doesn't like Emoji.
- RIMR 2y ago
  I tried to reply to this with just an emoji, and HN failed silently.
  - deleted 2y ago
    [deleted]
codedokode 2y ago
Please let me rant a bit about X11 input APIs. One of the major flaws in X11 is its poorly designed keyboard input system. When a key is pressed, the keypress event sends a "keycode" - an 8-bit number that references the current layout. This means you're limited to injecting characters that are present in the current layout. The implications of this design are frustrating. For instance, if you're connecting to a remote system via VNC and the client and server have different keyboard layouts, you'll run into all sorts of issues. Similarly, how do you create an on-screen keyboard that can inject keypresses for characters not available in the current layout? And what if you want to programmatically send some text, but the user has the wrong layout active? It's a mess. I guess because of this in Debian most of characters in on-screen keyboard didn't work (they "fixed" it by showing only characters present in active layouts instead of fixing the root issue). The common workaround for this is an ugly hack: you modify the keyboard layout, find unused spots, add desired characters, send key press event and restore the keyboard layout back. See the code: [2] Also, Wayland which was supposed to get rid of legacy problems, seems to have inherited this ugly design. Also, there seem to be no sane API for managing layouts or switching them programatically, or subscribing to layout change event. Also, you cannot use modifiers like Ctrl to switch layouts because then combinations like Ctrl + C stop working. Keyboard APIs on Linux are broken in the worst way possible since beginning, probably because most developers use only ASCII and do not have experience using multiple layouts. A better idea would be to allow to send arbitrary Unicode strings and maybe integrate regular input and IME input (input system for typing Asian characters). [1] https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#events:input https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.ht... [2] https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/keyinjector.c#L146 https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/ke...
- Zirias 2y ago
  For Wayland, keyboard input is "out of scope". (edit: Not entirely, just verified it does forward very basic events, but it's a thing wayland doesn't want to handle, while X11 originally had its own keyboard/mouse/etc drivers) What's typically used is XKB (inherited from X11) with a different backend ([edit: raw events]). So yes, in practice, you'll have the same broken design. > Also, there seem to be no sane API for managing layouts or switching > them programatically Layouts only exist as "data" as far as the X server is concerned, clients must fetch them and map themselves from the key codes. Libraries like xkbcommon (or even grandfather Xlib) do the job for you. That said, there are APIs to modify the mapping (by publishing messages/events) as you wish. The ugliness is, apart from the fact that you're forced to fiddle with the mapping at all, that you can't guarantee another client will process everything in sequence. It might apply a new mapping before processing all its queued key press events. That's why my code adds delays between fiddling with the mapping and sending the events. Yes, it's extremely ugly. Still, at least for me, it works. Try it out ;) And yes, Windows is doing better here, there's a Unicode-flavor of keyboard events available.
codedokode 2y ago
Also, I am curious: why in X11 and Wayland keyboard code translation happens on the client side? Wouldn't it make more sense if the layout was stored only on the server and server did the translation? There would be no need to broadcast layout changes, for example.
- aidenn0 2y ago
  The only thing I can think of is that some clients might want raw keyboard events. It does seem to me (an outsider) like Keysyms are the better level of abstraction for input for the overwhelming majority cases, and the translation should happen as early as possible in the server, and that's even before ignoring things like the asynchronous nature of xlib making keyboard remapping &c. unreliable for sending key events outside of the primary keymap.
  - codedokode 2y ago
    But you can send both raw key codes and translated character code and let client decide what it needs (for example, for hotkeys like Ctrl + C you will probably prefer a raw key code so that it works independent of selected input language).
- zzo38computer 2y ago
  I had thought to design the window system and operating system, that the keyboard manager will handle the keyboard translation and can be set to several modes by application programs. Only the server knows the keyboard layout, although clients can tell the keyboard translation modes: - Text input with large character sets (Extended TRON Code) - Text input with small character sets (the application program can select which one (although it is not guaranteed to be available, unless the user installs an appropriate keyboard layout); e.g. APL character set) - Command mode - Game mode - Hybrid mode This way it can handle IME as well, and also specialized layouts for purposes (such as APL programming), and can handle nearly raw keyboard events when desired (although, for purposes of security and others, some combinations might still be handled by the operating system or by the window manager).
avidseeker 2y ago
Reminds me of Tom Scott's "Art of Bodge up" video where he attempts to make an emoji keyboard on Windows. https://www.youtube.com/watch?v=lIFE7h3m40U https://www.youtube.com/watch?v=lIFE7h3m40U It's funny at the end he says "and don't ever suggest me I use Linux, just don't." I felt he expected it to be really hard project on Linux, while iterally his project is a single keyboard layout file.
- deleted 2y ago
  [deleted]
Jach 2y ago
I just use IBus, since I was already using it for Japanese IME input. It has its own emoji picker but has been kinda buggy before, instead I just use the "Typing Booster" keyboard option. I can type "wolf" and it'll popup a menu including the emoji or related emojis; I guess "cat:" is a better example since there's a lot more (e.g. shows tiger eventually) and I can scroll through them.

131 points by Zirias 2y ago

Nice project! Made me think of the emoji physical keyboard from Tom Scott https://youtu.be/3AtBE9BOvvk https://youtu.be/3AtBE9BOvvk

deleted 2y ago

[deleted]

Zirias 2y ago

In case someone wonders what's "special" about it: user perspective: As far as I know, it's the only tool offering somewhat reliable emoji input using faked X11 keyboard events. "x11-emoji-picker" comes close, but delegates faking events to "xdotool", with weird consequences like having to restart it to direct emojis to a different window ;) hacker perspective: It directly integrates xcb in a different event loop (here based on pselect()) and actually works – xcb is IMHO pretty great except for pretty much enforcing its own async model, internally using poll() and reading from the X server into buffers at many occassions, hidden from the consumer. If all your app does is communicate with the X server, you just happily use xcb's model. As soon as you need different things (e.g. local timers), you have a problem. The typical way to address that is dedicating another thread to xcb (AFAIK also done that way by toolkits offering an X11 backend). I hated that idea enough to be stubborn about doing it directly in my main thread, and with quite some trial-and-error, finally succeeded.

1oooqooq 2y ago
why not use xcompose?
- Zirias 2y ago
  Not sure you really mean the compose mechanism provided by Xlib (and xkbcommon etc ...)? If so, this wouldn't work for all these emojis that are represented by grapheme clusters, ZWJ-sequences or are just "qualified". The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint. Even for those emojis consisting of a singe codepoint, it would really miss the point. There are LOTS of emojis available, an emoji keyboard (or emoji picker) shows them organized in groups and allows searching for them.
  - 1oooqooq 2y ago
    i enter the five emojis i ever need to use by pressing <multikey>+u and then typing the emoji word. i think i can use skin color thumbs up just fine. but yeah, no search. but also no extra windows. when i asked i assumed compose + something like an IME could solve both with the search/window being optional.
    - Zirias 2y ago
      Xcompose only offers sequences started with the "compose" key (whatever it is mapped to) and resulting in a single X key-symbol, so to type an emoji needing multiple uniciode codepoints that way, you'd have to enter multiple "compose sequences". Whatever you describe here is not simple Xcompose. AFAIK, GTK offers entering unicode codepoints in a similar way ... Of course you can do a lot of things with "input methods" (like popping up some "picker" only when wanted). But then you'll depend on X clients being aware of them in some way, e.g. by implementing the XIM protocol. Lots of applications have that (even xterm), so it might be what you prefer and that's fine. My method with faked key press events is definitely hacky, but will work with any X client, that's the point of it ;)
      - numpad0 2y ago
        Are there any major apps that don't support XIM? An IME is required for CJK languages, so there shouldn't be apps that meet (in common use && have CJK users && not supporting IME) criteria. Implementation is beyond my ability, but if en-US locale were to finally adopt IME, I think it should be semi-trivial to include an optional dictionary file trained with emoji :tofu_on_fire: notation.
      - kps 2y ago
        > Xcompose only offers sequences started with the "compose" key (whatever it is mapped to) Not correct. For example, on my usual keyboard layouts¹, I use sequences starting with <dead_A> and <dead_U> for superscripts and subscripts. > and resulting in a single X key-symbol Also not correct. I certainly have a few non-single-keysim entries in my .Xcompose, e.g. <Multi_key> <R> <2> ↦ ℝ². ¹ https://github.com/datatravelandexperiments/kps-keyboard-layouts https://github.com/datatravelandexperiments/kps-keyboard-lay...
- kragen 2y ago
  i do love me some xcompose (https://github.com/kragen/xcompose https://github.com/kragen/xcompose) but being able to see the possible options is pretty nice
  - deleted 2y ago
    [deleted]
deleted 2y ago
[deleted]

elflaune 2y ago

as long as i need to run nvidia with multiple monitors, i'll hang on to x11.

spupy 2y ago
Is there an issue with Wayland for your setup? I run Gnome + Wayland on Fedora, with two monitors with different sizes and different refresh rates - eerything seems to run pretty fine, including gaming?
- cheeseomlit 2y ago
  Not OP but the last time I tried Wayland was about a year ago (also on Fedora) and I had similar issues using multiple monitors with different refresh rates, ended up switching to x11 which resolved it (using an nvidia card with nonfree drivers if that matters). But it seems I'll have to give Wayland another try if they've addressed it since then, I hadn't been keeping up with it.
cies 2y ago
We're in 2024Q3, things have improved. Nvidia helped out. (X)Wayland/KDE/Qt/GNOME bugs were fixed. Apart from that, use X11 as long as you wish! I'm just glad we can finally improve the open source desktop-environment infrastructure to match those of Windows and macOS: we've been stuck for too long.
- LeeCyriaca 2y ago
  X11 was and still is superior to wayland
  - WD-42 2y ago
    My tearing-free window movement begs to differ
    - Longhanks 2y ago

3np 2y ago

Looks promising! I think I did managed to wrangle fcitx into some reasonable emoji input in the past but at some point it broke / I lost it and configuring that tool is just an unpredictable mess... Will keep an eye on yours!

Zirias 2y ago
Using input methods is the "technically best" solution of course, but it needs configuration and some application support, therefore I wanted something working with "plain X" :) Sending fake key events is unfortunately "hacky". You need to temporarily switch the keyboard mapping, and many X applications have races between applying a new mapping and processing key press events, that's why I added (now configurable, new release soon) delays... and also, I found applications (e.g. chromium) having issues to correctly combine ZWJ sequences from individual key events, so I added more "hacks" to help with that, also just made configurable. To sidestep these issues, my tool also offers transfer via "primary selection": Just middle-click an emoji to select it, and middle-click again where you want to insert it. Downside: Two clicks instead of just one.

fao_ 2y ago

> As far as I know, it's the only tool offering somewhat reliable emoji input using faked X11 keyboard events. A few years ago I wrote https://gitlab.com/finnoleary/zhmenu https://gitlab.com/finnoleary/zhmenu (excuse the deadname in the URL there). I'm reasonably sure it partially counts? I'd meant to build an emoji database for it but never got around to it.

deleted 2y ago

[deleted]

dark-star 2y ago

Writing a pure X11 application in 2024 is an interesting choice, given the recent push to Wayland. Nevertheless, it looks like a pretty cool tool!

destructionator 2y ago
The recent push to Wayland in 2024 is an interesting choice, given how productive and usable X11 is.
- Zambyte 2y ago
  I'm very glad people made the push! My configuration has been much nicer being based on Wayland for the last 4 years or so than it was on X. Screentearing and limited refresh rates on mixed Hz setups are now a thing of the past :)
- WD-42 2y ago
  Have fun yelling at that cloud for the rest of time.
- talldayo 2y ago
  x11 is depreciated. It has no active maintainers and barely even qualifies for "maintenance mode" status; the push to remove Xorg can be justified by enumerating the security issues and nothing else. Strictly speaking Linux is "productive and usable" with nothing but a terminal multiplexer and a shell to work with. With expectations as high as they are in 2024, I don't think former Windows or Mac users will feel at-home with an x11 session. Switching away from bazaar-style software development is a prerequisite for the Year of the Linux Desktop.
  - mouse_ 2y ago
    I really do like Gnome and Wayland. I use them every day. That being said, Bazaar-style software development is the sole advantage free desktop has over macOS and Windows.
    - 2y ago

amelius 2y ago

Unicode sucks. There is a glyph for a hammer, for a screwdriver, but not a soldering iron. During COVID, people were using a golf club as a substitute for a cotton swab. We now have generative AI that can make any desired emoticon you can dream of, except you can't use it because of Unicode.

Y_Y 2y ago
Ya let's integrate gpu-accelerated emoji generation into unicode and require it everwhere, we can call it UTF-8B and standardize on 8GiB per character until that turns out not to be enough.
- account42 2y ago
  UTF-8 is innocent here, it's just a (very clever and useful) encoding of Unicode. The problem is adding junk codepoints based on current political ideology, not how they are encoded.
  - toast0 2y ago
    If you use a consortium governed character set, you get the problems of government by consortium. Probably still better to have a versioned universal set than so many to choose from.
  - Y_Y 2y ago
    For the record, I like utf8, I was just being silly.
  - Zardoz84 2y ago
    > junk codepoints based on current political ideology What do you mean ?
    - jandrese 2y ago
      Maybe ability to turn skin color brown? Or maybe the poster is mad that some country flag was or wasn't included? The only other distant possibility is how some character sets turn the gun emoji into a water pistol, but that's not on the Unicode consortium. I can't think of anything else that is political in the set.

yoavm 2y ago

I just have this one liner for Wayland: cat ~/.local/share/emojis/emojis| wofi -i -d -M fuzzy -H 700 | cut -d " " -f 1 | tr -d '\040\011\012\015' | wtype - It shows an overlay fuzzy-searchable list of all emojis, and it writes selected one to the input regardless of the toolkit. assign it to a keyboard shortcut and you're good to go. the ~/.local/share/emojis/emojis file is just a list of all emojis: cat ~/.local/share/emojis/emojis | head -n 3 Grinning Face Grinning Face with Big Eyes Grinning Face with Smiling Eyes (HN is removing the emojis but each line starts with the emoji self, followed by the description)

Zirias 2y ago
Note input is "out of scope" for wayland and XKB is used there for keyboard input as well. I just had a quick glance at "wtype" source and indeed, it fiddles with the keymap, using xkbcommon. So, assuming a suitable X11 replacement for this "wofi" tool, you could do exactly the same on X11 using "xdotool".
- yoavm 2y ago
  Indeed nothing special about Wayland for this, I have used `xdotool` in the old X11 days.
Y_Y 2y ago
And where can one obtain this `emojis` file?
- quotemstr 2y ago
  You know, we should add an emojis dictionary to http://wordlist.aspell.net/ http://wordlist.aspell.net/ for exactly this purpose. Why not have a /usr/share/dict/emoji just like we have /usr/share/dict/words?
- yoavm 2y ago
  here it is: https://gist.github.com/bjesus/4b447dcb8a272f4c795b78752acec75f https://gist.github.com/bjesus/4b447dcb8a272f4c795b78752acec...

freedomben 2y ago

Fun project, thanks for sharing! On Gnome there is the "Characters" application which is pretty handy. I do want to make a few improvement to search, but otherwise it's pretty good. You copy the unicode character to the clipboard and can then paste it wherever you need. If you run Gnome it's probably already installed. If not: https://gitlab.gnome.org/GNOME/gnome-characters https://gitlab.gnome.org/GNOME/gnome-characters

seltzered_ 2y ago
There's also a gnome-based app called Smile: https://github.com/mijorus/smile https://github.com/mijorus/smile
- freedomben 2y ago
  Neat, thanks for sharing! This just replaced "Characters" for me. Seems really well done, and most importantly the search works well and it has "recents". I do wish it wouldn't automatically close itself after clicking/copying an emoji, but I try not to let perfect be the enemy of good :-)
Zardoz84 2y ago
KDE/Plasma comes with a Emoji selector. It usually can be launched with Super+.

jandrese 2y ago

This is a cool project, but hard to show off since HN doesn't like Emoji.

RIMR 2y ago
I tried to reply to this with just an emoji, and HN failed silently.
- deleted 2y ago
  [deleted]

codedokode 2y ago

Please let me rant a bit about X11 input APIs. One of the major flaws in X11 is its poorly designed keyboard input system. When a key is pressed, the keypress event sends a "keycode" - an 8-bit number that references the current layout. This means you're limited to injecting characters that are present in the current layout. The implications of this design are frustrating. For instance, if you're connecting to a remote system via VNC and the client and server have different keyboard layouts, you'll run into all sorts of issues. Similarly, how do you create an on-screen keyboard that can inject keypresses for characters not available in the current layout? And what if you want to programmatically send some text, but the user has the wrong layout active? It's a mess. I guess because of this in Debian most of characters in on-screen keyboard didn't work (they "fixed" it by showing only characters present in active layouts instead of fixing the root issue). The common workaround for this is an ugly hack: you modify the keyboard layout, find unused spots, add desired characters, send key press event and restore the keyboard layout back. See the code: [2] Also, Wayland which was supposed to get rid of legacy problems, seems to have inherited this ugly design. Also, there seem to be no sane API for managing layouts or switching them programatically, or subscribing to layout change event. Also, you cannot use modifiers like Ctrl to switch layouts because then combinations like Ctrl + C stop working. Keyboard APIs on Linux are broken in the worst way possible since beginning, probably because most developers use only ASCII and do not have experience using multiple layouts. A better idea would be to allow to send arbitrary Unicode strings and maybe integrate regular input and IME input (input system for typing Asian characters). [1] https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html#events:input https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.ht... [2] https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/keyinjector.c#L146 https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/ke...

Zirias 2y ago
For Wayland, keyboard input is "out of scope". (edit: Not entirely, just verified it does forward very basic events, but it's a thing wayland doesn't want to handle, while X11 originally had its own keyboard/mouse/etc drivers) What's typically used is XKB (inherited from X11) with a different backend ([edit: raw events]). So yes, in practice, you'll have the same broken design. > Also, there seem to be no sane API for managing layouts or switching > them programatically Layouts only exist as "data" as far as the X server is concerned, clients must fetch them and map themselves from the key codes. Libraries like xkbcommon (or even grandfather Xlib) do the job for you. That said, there are APIs to modify the mapping (by publishing messages/events) as you wish. The ugliness is, apart from the fact that you're forced to fiddle with the mapping at all, that you can't guarantee another client will process everything in sequence. It might apply a new mapping before processing all its queued key press events. That's why my code adds delays between fiddling with the mapping and sending the events. Yes, it's extremely ugly. Still, at least for me, it works. Try it out ;) And yes, Windows is doing better here, there's a Unicode-flavor of keyboard events available.

codedokode 2y ago

Also, I am curious: why in X11 and Wayland keyboard code translation happens on the client side? Wouldn't it make more sense if the layout was stored only on the server and server did the translation? There would be no need to broadcast layout changes, for example.

aidenn0 2y ago
The only thing I can think of is that some clients might want raw keyboard events. It does seem to me (an outsider) like Keysyms are the better level of abstraction for input for the overwhelming majority cases, and the translation should happen as early as possible in the server, and that's even before ignoring things like the asynchronous nature of xlib making keyboard remapping &c. unreliable for sending key events outside of the primary keymap.
- codedokode 2y ago
  But you can send both raw key codes and translated character code and let client decide what it needs (for example, for hotkeys like Ctrl + C you will probably prefer a raw key code so that it works independent of selected input language).
zzo38computer 2y ago
I had thought to design the window system and operating system, that the keyboard manager will handle the keyboard translation and can be set to several modes by application programs. Only the server knows the keyboard layout, although clients can tell the keyboard translation modes: - Text input with large character sets (Extended TRON Code) - Text input with small character sets (the application program can select which one (although it is not guaranteed to be available, unless the user installs an appropriate keyboard layout); e.g. APL character set) - Command mode - Game mode - Hybrid mode This way it can handle IME as well, and also specialized layouts for purposes (such as APL programming), and can handle nearly raw keyboard events when desired (although, for purposes of security and others, some combinations might still be handled by the operating system or by the window manager).

avidseeker 2y ago

Reminds me of Tom Scott's "Art of Bodge up" video where he attempts to make an emoji keyboard on Windows. https://www.youtube.com/watch?v=lIFE7h3m40U https://www.youtube.com/watch?v=lIFE7h3m40U It's funny at the end he says "and don't ever suggest me I use Linux, just don't." I felt he expected it to be really hard project on Linux, while iterally his project is a single keyboard layout file.

deleted 2y ago
[deleted]

Jach 2y ago

I just use IBus, since I was already using it for Japanese IME input. It has its own emoji picker but has been kinda buggy before, instead I just use the "Typing Booster" keyboard option. I can type "wolf" and it'll popup a menu including the emoji or related emojis; I guess "cat:" is a better example since there's a lot more (e.g. shows tiger eventually) and I can scroll through them.