The UK Extended keyboard -- over-extended? Or weirdly extended?

by Michael S. Kaplan, published on 2007/11/29 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/11/29/6594984.aspx


I have a regular reader who is kind of fond of the blog. She admits to skimming it regularly, kind of a Category B, Cliff Notes version kind of reader.

Though she also admits that posts about keyboards bore the hell out of her, so once she sees a post is about keyboards, it gets skipped.

Now that both posts today are clearly about keyboards, it is safe to say that the day is just going to be downhill from here for anyone who shares her opinion on these things....

However, the needs of the many out weigh, etc, etc. etc.

Apparently, she isn't reading this, based on the filtering by title, so everyone pretend I made a really amusing joke at her expense (I can't think of one offhand). :-)

Okay, on to the post....

Over in the Suggestion Box, DrPizza asked:

  1. I use the "United Kingdom Extended" keyboard layout with English (United Kingdom); it's like a cross between the UK layout and the "United Stats-International" layout (why one should be "international" and the other "extended", and why one should have a hyphen in its name and the other not is beyond me).  Whenever I RDP into my Vista machine, Vista adds, and switches to, the Welsh input language, still using the UK Extended layout.  This is infuriating.  What gives, and is it possible to prevent it?
  2. Given the death of the Unicode IME (which was never especially satisfactory) is there any plan to ever have a non-sucky way of entering otherwise untypable characters?
  3. Is there any way to make keyboard layouts with a compose key, instead of the dead key mechanism?  e.g., using alt-gr as compose, letting me type alt-gr, o, e, (sequentially, no need for concurrent key-presses) to get an œ ligature.

I'll take these in reverse order, as I think that will allow my answers to become more satisfying/fulfilling, rather than less so....

For the third item, there is no way to extend the low level keyboarding mechanism in this way, as it truly is a data-based mechanism backed by data "tables" of information, making a generative model such as that impossible, as would altering the behavior of shift keys so markedly....

For the second item, there are of course already many other methods of inputting such data that exist, covered in posts like Typing in random Unicode code points and those who don;t want to wait for Microsoft do something better can emulate Andrew as I pointed out in Typing in random Unicode code points redux. Better mechanisms are not a bad idea in my opinion, and something more central rather the constant inclusion of features in random components/applications like ALT+X support in RichEdit/Word.

Questions like what such a mechanism would/could be, where would it sit, and who would own it are of course ones that would need to be answered, though without a really clear sense of usability (remember that most users of Windows don't even know what Unicode is, let alone what code point values map to what characters -- so this is a hard scenario to claim as mainstream!).

And then there is that first question, the only one I feel I had good answers for! :-)

Of course the name silliness is not really question anyone can answer, other than the abject fear that the cleanup of the names would lead to a support hit as people called to complain about the changes. :-)

So let's stick to the technical bit, which has an answer!

Let's look at the United Kingdom Extended keyboard in its place in the registry:

You may see it right now -- the KLID value for this keyboard? Its 00000452, and that attached LANGID is the one for cy-GB, aka Welsh (United Kingdom).

Regular readers my recall some of the blathering I did in Keyboards over Terminal Server, where the way that keyboard layouts on the client side are picked up and added in a non-permanent fashion on the Terminal Server.

The behavior DrPizza describes give some insight into how that is accomplished -- by using the KLID value without picking up the language information from the HKL itself.

So that takes care if the first part of the question (what gives?) though unfortunately there is no way to stop other than creating a custom keyboard in MSKLC that you put on both client and server, based on the language you want the server to pick up....

 

This post brought to you by(U+09fa, aka BENGALI ISSHAR)


# John Cowan on 29 Nov 2007 11:16 PM:

Let me remind you again of Gwalla's superb US-Latin1 keyboard (which would be easy to adapt to U.K. style, I think).  It provides full access to the Latin-1 repertoire without changing the effect of any key except AltGr -- no dead keys.  To enter a-acute, for example, simply type Alt-Gr-apostrophe followed by a.  When I was still on Windows at all, it was my very favorite keyboard, usable for coding *and* writing internationalized email.

You can fetch it from http://gwalla.livejournal.com/39856.html .

# Michael S. Kaplan on 29 Nov 2007 11:25 PM:

I'm confused, John -- the last time I looked at this one, it had dead keys, in the AltGr state. what do you mean about there being no dead keys -- is there another version of the layout?

# Dr Pizza on 30 Nov 2007 7:38 AM:

Ok cool.

Isn't the terminal server behaviour a bit, well, silly?  I mean, it's not immediately clear to me why a keyboard layout should have a language ID in the first place (the OS maintains language and keyboard layout as distinct concepts, which is how I can use UK English with UK Extended in the first place) but OK, I accept that for whatever reason it does.  What I don't see is why TS should use that keyboard layout-defined language and not, y'know, the actual language I'm using.

Regarding a way of entering arbitrary codepoints; the extended (hexadecimal) number pad method is the one I'm using at the moment, but it doesn't work properly; some programs trap alt+keypress, and the unicode entry isn't hidden from them.  For example, typing in the IE address bar, anything using a hexadecimal 'd' doesn't work.  It seems to me that once you've begin a unicode keystroke sequence, VKs shouldn't be delivered to the application until you've finished.  The escape sequence should be totally invisible to the application.  Some kind of visible feedback would be nice, too.

The inability to support 'compose' is rather sad.  'compose' is much friendlier, IMO, as it requires fewer contortions.

# Michael S. Kaplan on 1 Dec 2007 11:19 AM:

I don't know if I would call the TS behavior silly, when there are so many on Office and elsewhere who find the whole "putting one language under another" to be silly....

# John Cowan on 3 Dec 2007 11:45 AM:

Well, yes.  I was speaking loosely:  there are dead key *states*, but there are no keys which are dead in either normal or shifted state, which is what makes the US-International keyboard obnoxious to use for code, where you are all the time typing "-space to quote a string.  I used to switch between US-QWERTY and US-International all the time until I found and adopted Gwalla for all purposes.

(Then I defenestrated myself.  I would never look back now, but I do miss my Gwalla.)

John Cowan on 26 Dec 2010 10:27 AM:

Well, I'm back on Windows (thanks to the new job), and got Gwalla to send me the keyboard, which has a new home at www.ccil.org/.../USInt2.zip .

Michael S. Kaplan on 26 Dec 2010 11:35 AM:

We're cooler anyway. Welcome back. ;-)


go to newer or older post, or back to index or month or day