Those keys aren't going to be extended; they're dead!

re: Those keys aren't going to be extended; they're dead!

Tom Gewecke — Fri, 19 Jun 2009 13:34:23 GMT

Deadkeys don't require that you type the accent first, do they? On a Mac you can make layouts where the vowel is the deadkey and what diacritic is added depends on the next key you hit.

re: Those keys aren't going to be extended; they're dead!

gbella — Fri, 19 Jun 2009 16:29:13 GMT

Hi, I just discovered your blog while searching for a solution for a MSKLC-related bug (? to be confirmed). I wonder if this is the right place to post such reports, but it will also allow me to reflect on your opinion about dead keys.

So let’s see this dead key issue first. Yes, combining characters are great, and I have nothing against the Unicode principle of them following the base character. However, and I’m sure you know this just as well as me, dead keys are commonplace for several non-US (e.g., French) keyboards. People are pretty well used to them, and these kinds of habits just don’t go away. Moreover, support for combining characters is a very recent addition to Windows: I am told they work under Word 2007 but, in my experience, not under Word 2003, which an awful lot of people still use. Also, under XP (e.g., Notepad), the equivalence of the base+combining pair and the precomposed character is not respected, which is a major issue (when searching for the word passé I won’t find passé, see the difference?).

Recently I considered deploying combining character-equipped custom keyboard layouts in a big company, but I immediately discarded the idea once I realised that these issues could not be resolved.

Which brings me to my main topic: while developing a custom French keyboard with MSKLC, I ran into a strange error which might be a bug. I was trying to reproduce some Word-specific French character combinations such as Ctrl+' which is basically a dead key for the acute accent. So in MSKLC I defined Ctrl+' (that is, VK4) as a dead key that gives ÁÉÍÓÚáéíóú when followed by AEIOUaeiou. Also, I wanted to used the same dead key to type a regular (i.e., typographic) apostrophe U+2019 when followed by a space:

U+00B4 (dead) followed by U+0020 => U+2019

It all works perfectly fine in the test window of MSKLC. However, when I create and install the DLL, the behaviour is altered: Ctrl+' is not a dead key anymore, and pressing it results in two (!) apostrophes (U+2019) being displayed. Upon opening the installed keyboard with MSKLC, I see that the key’s definition has indeed changed: Ctrl+VK4 gives U+2019 U+2019.

A similar, although not equivalent, problem occured when trying to define Ctrl+è (that is, VK7) as a dead key for the grave accent. This time, once the custom keyboard installed, the combination Ctrl+è becomes AltGr+è.

The KLC source file contains the right information. These alterations occur with the installed package only.

Any solutions or ideas? I can provide you with more information or the source KLC file if necessary.

Thanks a lot in advance, cheers,

Gábor

re: Those keys aren't going to be extended; they're dead!

Michael Everson — Fri, 19 Jun 2009 17:05:18 GMT

Lots of people are very happy with dead keys, and have been for decades. Irish keyboards, for instance, and most of the keyboards on the Mac OS, used deadkeys. You might (and do, as you say) prefer other methods of input, but there's a big difference between that and telling those who don't that they are benighted and should adopt different methods of input.

re: Those keys aren't going to be extended; they're dead!

Michael S. Kaplan — Sat, 20 Jun 2009 20:55:04 GMT

Hey Tom -- on Windows, the dead key architecture is only accent+base. The Mac has many clever additions that make dead keys more usable, but as I said Microsoft does not consider the are worth expanding on, so they do not plan to....

re: Those keys aren't going to be extended; they're dead!

Michael S. Kaplan — Sat, 20 Jun 2009 20:59:34 GMT

Michael, I don't know what to tell you -- I am describing things as they are and (barring some tumultuous intervening event by someone a lot more powerful than either of us) as they will be on Windows.

People who want to work on Windows can use the dead key support that is there and which works for many languages, or they can use other methods. There are realistically no other options....

re: Those keys aren't going to be extended; they're dead!

Michael S. Kaplan — Sat, 20 Jun 2009 21:06:05 GMT

Gábor, for your bug you should see other blogs I wrote like this one and this other one....

re: Those keys aren't going to be extended; they're dead!

RQ — Fri, 26 Jun 2009 11:00:56 GMT

Michael,

thanks for answering! :)

I had read many of your posts (especially those related to the question) before, but the reason why I re-asked this question was because it seemed to me that this limitation is mostly kept just to be kept. You said:

Even if this ever were changed in a future release of Windows, it could not be used on existing versions due to the backcompat break that this would cause -- and the future version of MSKLC would have to support different keyboard layout DLLs for different versions of Windows. Which as I am sure people can imagine is not a terribly popular plan....

So, it seems to me that it's not being updated purely for the sake of backwards compatibility, and while backcompat is a good thing, I don't believe that it should block progress (otherwise we would still be using DOS, wouldn't we?). Sure, I understand that even if Windows 8 would extend the possibilities here, we would still have to work around the limitation for Windows 7, Vista, XP etc. That's normal. Not so normal is limitations in legacy systems causing limitations in new ones. I hope you get my point... :)

re: Those keys aren't going to be extended; they're dead!

Michael S. Kaplan — Sat, 27 Jun 2009 19:14:50 GMT

The code is very solid as is and rearchitecting it to support a new scenario is considered out of scope (plus would add huge complexity to layout maintenance given the forward and backward compatibility issues.

This is not "kept just to be kept" this is kept to avoid a huge engineering cost for Microsoft and third parties and a huger authoring/maintenance cost for third parties.

It will not happen for the USER-based keyboarding architecture on Windows.

Now this does not mean the general problem has no possibility of solution; it just means that the one technology in question does not have it. There are methods to make the old architecture work (as I mentioned) and explorable avenues to use new architectures (like the text-based TIPs I have discussed previously)....