Live data from Hacker News

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

github.com

71–80 of 102 posts

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

#71

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 remo…

> Also, there seem to be no sane API for managing layouts or switching them programatically, or subscribing to layout change event

X11 has XkbMapNotify/XkbStateNotify.

Wayland has a wl_keyboard.keymap event.

> 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).

Not particularly, the difficulty here is that some clients want text input, and some clients really do want key events (e.g. think games where holding W does not really have much to do with the Unicode code point 'w'). This was discussed for a long time, and the current design was decided as the best option.

IME systems do exist and already work just fine; they are integrated client-side. IME systems cannot really be integrated into the protocol since many of them involve custom UI.

That said, there's a proposal for an "input-method" extension which lets you commit text directly, but I don't think anybody is actively championing it. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

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

#72
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

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.

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

#73

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.

I mean you're free to fork and continue developing X11; right now there is nobody with both the capability and the desire to do so.

I'd wager that once I get hardware made in 2024, Wayland may work well for me (though in its defense it does work fine on my one machine with an Intel integraded GPU), but for now none of my (very old) discrete GPUs work reliably with Wayland, with 2 GPUs and 3 drivers (nvidia vs nouveau for my old GeForce and "radeon" (not amdgpu) for my old AMD card) causing 3 symptoms:

1. Crashes immediately on login

2. Black Screen

3. Kind-of sort-of works, but sometimes the screen just freezes for no reason and sometimes switching VTs fixes it sometimes not.

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

#74

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.

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).

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

#75

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.

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…

I don't think you need translation modes; you could simply send both raw events and translated events simultaneously and let client choose what it needs.

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

#76
post #70

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.

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 event…

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).

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

#77

Earlier quoted context omitted.

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…

I don't think you need translation modes; you could simply send both raw events and translated events simultaneously and let client choose what it needs.

I do not agree. Translation modes will be necessary in order to handle IME properly, as well as for handling specialized character sets. (It may also mitigate some types of spying, possibly.)

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

#78

Earlier quoted context omitted.

> junk codepoints based on current political ideology What do you mean ?

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.

I dont want to supply munitions to the culture war, but I would like to add a counterpoint.

Adding skin tone modifiers to emojis was a bit odd to me, since I view them as signifying emotions rather than people. Maybe that's why, of the six Fitzpatrick scale[0] skin tones they drew from, the only one not added was mine.

Similarly odd to me (to the point of appearing performative) was having a male/female/ambiguous variant on every job emoji and a separate option for every two-child two-parent family "gender" permutation. That's not how I view language as working, particularly because you're not going to be able to cover all valid families that way. It makes more sense to me, if communication rather than tokenism is the goal, to have a couple of representative emojis that convey the general concept, and then specify whatever you want about the relevant people afterward.

[0] https://en.wikipedia.org/wiki/Fitzpatrick_scale

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

#79
post #6
post #5

Earlier quoted context omitted.

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 po…

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.

What is multikey?

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

#80
post #71

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 remo…

> Also, there seem to be no sane API for managing layouts or switching them programatically, or subscribing to layout change event X11 has XkbMapNotify/XkbStateNotify. Wayland has a wl_keyboard.keymap event. > 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). Not particularly, the difficulty here is that some c…

> Not particularly, the difficulty here is that some clients want text input, and some clients really do want key events

I understand this point. For this case it makes sense to send both key code (what character does the key map in Latin layout) and translated code (which characters will be printed when key is pressed in current layout). It seems an easier solution than broadcast large structures to every client and let them have each own implementation for translating codes.

Regarding IME, I meant not integrating IME client into a Wayland server but instead unify the API and events that IME uses to insert text with API and events used to notify about regular keypresses.

Post reply on HN