51–60 of 102 posts
Earlier quoted context omitted.
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…
> 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 and 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. ↦ ℝ². ¹ https://github.com/datatravelandexperiments/kps-keyboard-lay...
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 (he…
This is a cool project, but hard to show off since HN doesn't like Emoji.
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!
The recent push to Wayland in 2024 is an interesting choice, given how productive and usable X11 is.
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.
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/sha…
I use rofi-emoji [0] on X11, and it's great. [0]: https://github.com/Mange/rofi-emoji
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
Earlier quoted context omitted.
i enter the five emojis i ever need to use by pressing +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.
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…
¯\_(ツ)_/¯
(or, as it's spelled through my .XCompose, shift-altgr 3 3)
I think there was a time when compose sequences could only emit a single character, at least in some contexts. But as far as i can tell, every text box in every app on my machine supports multi-character sequences.
Earlier quoted context omitted.
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.
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.
What do you mean ?