try to fix extended char handling in NSEvent

[rmottola]

Issue described in #49

I found out that sometimes XLookupString returns more than one char for a single key, which does not make much sense for Latin1.
So I suspect I am getting back UTF-8 in that case and indeed, interpreting that string as such works!

Looks like X11 got "extended" here beyond the Spec that says Latin1 only. The question remains why it is happening for characters contained in Latin1?
Last found is that €, not contained in Latin1 gets not back.

However I think this "hack" is pretty safe, since if only one char is returned, Latin1 is used as per-spec.

[rmottola]

Addendum. Actually also € works! It is returned as 3 chars and is interpreted correctly.
What confused me is that its value for ukeys (that is without modifiers) is 'e', while for è keys and ukeys are both 'è'

[rmottola]

Tried on Linux where I had no issues and continue having no issues with Italian keyboard.

Would you mind testing e.g. with German keyboard?

[fredkiefer]

I wanted to test, whether we could switch to NSUTF8StringEncoding even when there is just one character. But as I didn't find the time to do so, it is probably better just to merge this change.

[rmottola]

@fredkiefer if you want somehow create a TODO and work with this on the next hacking session together or if I should test a patch for you, I'm available! In the meanwhile we see if this change creates issues.

[rfm]

I think the change is good. If the data is utf-8 a single byte is guaranteed to be correct latin1. If the data is latin1, it's either got the top bit set (and would be invalid utf-8) or it hasn't (and it's the correct ASCII value). So it seems very safe to me.

[rmottola]

@rfm thanks for you opinion, I was a bit wary about this because it is somehow against documentation of X11 and I saw 2 or 3 bytes and was attempted at trial-and-error, but it is safe for 1byte.