How to use UCIS properly?

[PureSpider]

Yesterday I tried to get UCIS working on my custom keymap and while I got it to do something, it wasn't what I wanted it to do. It seems like it just hit some random keys and left alt a bunch of times. It tried copying from the keymap made by @algernon for the ergodox but couldn't get it to work.

What are the steps I need to take to get this working? Might it be that I'm using the German keymap that messes things up?

[algernon]

It depends a lot on the operating system too. What OS are you using?

[PureSpider]

I am using Windows 10 and I set the unicode mode to Windows for that, still didn't work properly.

[priyadi]

Today I spent some time testing Unicode input on Linux, Windows and Mac OS. These are my observation.

• Windows 10: Had some very bizarre problems. Inputting 0x270C results in 0x010F in Word, but results in correct character in Notepad. Inputting 0x1F601 results in 0xF601 in Notepad, but 0x641 in Word. Sometimes apps will see that the Alt is depressed, and act accordingly, i.e. Alt-F = open file menu.
• Mac OS X El Capitan: Will not accept code above 0xFFFF. Didn't test much else.
• Linux: Works great with ibus, but some applications don't support ibus (for example: Sublime). Supports up to 0xFFFFF, but that's plenty for now.

[priyadi]

My conclusion: Works quite reliably under Linux. Probably works great under Mac OS for any characters up to 0xFFFF. Useless under Windows, at least under my Win10.

[PureSpider]

Sometimes apps will see that the Alt is depressed, and act accordingly, i.e. Alt-F = open file menu.

That's what I observed as well... oh well, it would have been nice to use it on my Windows 10. Is there any alternative to input unicode characters?

[priyadi]

This looks promising: https://github.com/samhocevar/wincompose

I can reliably input 0x1F601 under Notepad, Word, IE and Chrome using: RAlt, u, 1, F, 6, 0, 1

Should be easily implemented in QMK. I'll make a pull request in a moment.

[priyadi]

@PureSpider I updated my firmware and I can confirm WinCompose method works pretty much everywhere under Windows. I'm using Unicode Map though, not UCIS, though both are using the same underlying unicode input method in QMK.

[PureSpider]

That means that WinCompose needs to be running though, right? That wouldn't be a problem for me, I just wondered.

Windows has combinations when you hold down the right alt key and then type a code on the numpad. Is that of any use here?

[priyadi]

@PureSpider According to this that would be method 2 or 3 which we can't rely on because those depend on the current regional setting being used on the OS. Besides, those won't cover the entire Unicode codebases.

[PureSpider]

Ah, got you, WinCompose seems like a nice way to do that sort of thing honestly. I will try setting the registry key mentioned in your link and see if the current Windows UCIS method works after that on monday.

[PureSpider]

With the registry key mentioned in number one here, the input works for characters under 0xFFFF in my Windows 7 install - in some applications, for some characters. Some applications and characters still just trigger on the Alt push and open the application menu.

For example, 0x2603 works fine in firefox, while 0x261d opens the menu. In Pidgin, the input doesn't work at all and is recognized as Alt pushes instead. Notepad++ handles all of the characters I tried fine.

Didn't have the chance to try it under Windows 10 yet. I will try Windows 10 and the WinCompose method on both soon and report back.

[samhocevar]

Hi, I’m the WinCompose author and I just found this ticket. It seems to me that the proposed solution would not work if the user configures a different key than RAlt as their compose key; is there anything we could devise together to get it to work in all cases?

[PureSpider]

I solved it by just adding a custom bit of code for my keymap to use whatever compose key I defined:

void unicode_input_start (void) {
    switch(get_unicode_input_mode()) {
        // ...
        // WinCompose with scroll lock as trigger key
        case UC_WINC:
            register_code(KC_SLCK);
            unregister_code(KC_SLCK);
            register_code(KC_U);
            unregister_code(KC_U);
    }
    wait_ms(UNICODE_TYPE_DELAY);
}

However, I found WinCompose to be unreliable and most of the time not recognizing the sequences entered.

The UCIS processing does this to show you're in unicode mode: register_hex(0x2328);, which comes out as Compose key + u2328 (which is ⌨) but it usually only registers it as an unicode input sequence for me when I type a space afterwards, which then subsequently screws up the actual UCIS input. If I don't type a space, it takes whatever character comes next as part of the unicode sequence (if hex), which then screws up the entire input. Hope this was somewhat clear, if not I can elaborate further. (This might also just be me screwing something up. What's WinCompose expecting to finish a unicode input sequence?)

As for a solution: with the upcoming bi-directional communication support (from keyboard to PC and PC to keyboard) there should be a way to tell the keyboard which compose key to use from the PC OR tell the PC which compose key the keyboard wants to use from the keyboard side.

[wilba]

I also found WinCompose a bit buggy when entering UNICODE sequences with RAlt... I think it expects an RAlt to finish? Somehow Notepad++ would think RAlt was stuck down and I'd have to reset the keyboard. I didn't even get to using QMK to send those sequences, since I couldn't even get it working properly with keystrokes.

[PureSpider]

Ideally there would be a small helper program with a subset of WinCompose's functionality, to only accept unicode inputs and that also communicates with QMK in some sort of fashion to figure out the compose key, in my opinion.