4 ms·
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 X1
by 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 agowhy not use xcompose?
- Zirias 2y agoNot 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 agoi 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 agoXcompose 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 agoAre 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...
- keybored 2y agoIndeed. In my experience you can use whatever mappings you want. Just grab a writing script that you never type in and go ham : `<Ethiopian_B> …` (Note: made up keysym).
- 2y ago
- account42 2y ago> The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint. Not true even if some broken toolkits impose that limitation.
- Zirias 2y agoThanks for the pointer, this made me have another closer look at xkbcommon's API. Probably not too relevent for the tool I'm currently writing, but I'll keep that in mind: Instead of a key symbol, you can also obtain an utf-8 encoded string. Nice. Still, in practice, it will only work with some applications...
- keybored 2y ago> 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. I use the compose key as an abbreviation expander among other things. So far this works fine in all applications. Though I don’t know if we’re talking about something beyond typing the XCompose sequence on the keyboard. If we’re talking about sending programmatic keypresses to applications like in this submission then I don’t know.
- kragen 2y agoactually it's possible to send multiple key symbols from a compose sequence; i have sequences for 'n’t ', ' — ' (with thin spaces), ' the ', ' The ', ' and ', ' I’m ', etc. see https://github.com/kragen/xcompose/blob/master/dotXCompose#L74 https://github.com/kragen/xcompose/blob/master/dotXCompose#L... but i agree that compose is not a great user experience
- kragen 2y agoi 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]