by Michael S. Kaplan, published on 2008/02/09 12:06 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/09/7564967.aspx
Over in the Suggestion Box, Alec McAllister asks:
I'm a long-time user of MSKLC, having made keyboard layouts to support many languages, but I'm stumped by one thing: does MSKLC allow a SGCAP+somekey combination to be used as a dead key, or not?
MSKLC offers a Dead Key option by such keys, allows us to create listings of characters, and correctly types those characters with that dead key in Keyboard Layout Testing. However, it seems reluctant to activate those dead keys when the DLL is built.
Hebrew and a few other layouts use SGCAP combinations, but not as dead keys.
Unfortunately, Alec isn't missing anything here.
Dead keys and SGCAPS don't mix.
It's funny, the organic and essentially spec-less process by which MSKLC was built is in some ways responsible for the many layers by which features ended up being added.
First came dead keys -- not supporting dead keys was considered a ship killer (an attitude which I was later able to inject into The Keyboard Convert Service, which initially did not support dead keys until I helped convince them that a) this was a really bad idea and b) that it was not too hard to add support for!
Then came SGCAPS -- which PM was actually against at first as it seemed extraneous. I persisted since their original goal (supporting as many keyboards from the ones we ship as possible) could not be met without SGCAPS support, and eventually they agreed that incomplete loading of all of those keyboards would not be such a great user experience....
Then came the test surface, that built-in way to test the keyboard without installing it. That one was entirely inspired by Bala, my lead at the time (he had never installed the beta builds of MSKLC until the release candidate but when he did he was really impressed with the exception of it requiring installation of the keyboard to try it out. We had a big conversation about mitigation strategies and based on an idea from Bala a prototype of that test surface was built. It proved to be the only option people (including Bala) really liked, so we decided to ship it....
The test surface was taking the data built-into the keyboard and just kind of applying it, without any notion of what may or may not work later. It was a wonderful idea, truly -- one I wish we would have added sooner since (as it turned out) very few people were actually installing their random test keyboards and testing them purely to find bugs -- and the test surface flushed out a lot of bugs!
But the fact that
all don't work as one might expect are limitations that a spec and the investigation into the covered feature set that the spec would be expected to include would probably have revealed.
In fact, as far as I can recall, only the first two of those bullet points have ever been reported -- Alec's report is a longstanding unreported MSKLC bug!
If one of the current owners of MSKLC would make sure that bug report gets put in the proper place, it seems like something to consider for next version -- locking down the UI so the dead key checkbox is disabled/hidden for those two shift states and the dead key dialog can't be reached from SGCAPS seems like a pretty good idea, since the UI is kind of writing checks that Windows keyboards can't cash....
This post brought to you by ✓ (U+2713, aka CHECK MARK)
referenced by