[Pretty much] All the things you can't do with SGCAPS, and why

by Michael S. Kaplan, published on 2010/07/07 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/07/07/10032340.aspx

So I got this note from Szabolcs via the contact link, and I am unfortunately way too late to help, but maybe it will be of help to someone:

Hello,

I came across your blog looking for help with MSKLC, I see that you have treated the topic several times. I hope, you can help me.

I'd like to devise a keyboard layout, which takes as a base an existing latin layout and adds a custom script to it via the SGCAPS switch feature. I have good reasons to add the script not as a different keyboard layout, but as SGCAPS.

On the other hand, I would not need all the keys on the SGCAPS shift state, so I'd like to have empty keys. Unfortunately, I could not figure out how: if I did not define any SGCAPS+<key> value, then, depending on wheather I set the "Caps==Shift", the 'unmapped' key won't be unmapped, but either result in the lower or upper-case version of the latin layout.

I'd like to ask you, how it is possible to have empty keys in the SGCAPS shift state.

<remark>
I have thought of the possibility of putting the alternative script into the unshifted state, and the latin one into the SGCAPS state, as I also could use (while do not need) multiple codepoints ("ligatures") mapped to a single key, which is (for me not quite clear reasons) impossible in the SGCAPS state, but this solution, having the primary script in the SGCAPS state seems, while perfect for me, unsatisfactory and unintuitive for packaging and distribution to a user community.
</remark>

Thank you very much,
    Szabolcs

The answer is probably not one that Szabolcs will like very much, which makes me feel kind of bad that it took me so long to get to answering it (since the answer won't help) but....

The problem is that SGCAPS as a feature is not very refined in the traditional feature sense (hopefully the original developer, who still works for Microsoft just  few buildings away from my office) will forgive my descriptions here!).

It was added to spec by a developer to add a specific described functionality, but that functionality not one that was given the full treatment to make it act like any other shift state.

In fact, if you look at the MSKLC development process -- hinted at in blogs like Do your utmost to be conventional (and then pimp, q.d. or p.r.n.), Accessibility, Internationalization, and Keyboards (#3: MSKLC's UI), and others -- the SGCAPS support was one that I told Cathy and Simon we couldn't do, and they agreed plus it didn't matter since we had no "load existing layout" functionality at the time. But it really bothered me, especially after we added "load existing layout" functionality, so I added it.

They were okay with it but a little concerned.

I often suspect that Cathy and Simon looked at me adding features like this the same way Shakespeare's Macbeth looked at murder -- initial uncertainty, followed by cautious enthusiasm, followed by a bit of horror about the magnitude of it all with no end in sight!

But the addition assumed it would act like all other shift states.

So over the course of the next few weeks, the tester ran into so many limitations that I had to go back and turn off SGCAPS in MSKLC in a bunch of cases. :-(

The limitations that Szabolcs mentions are real ones that I added to MSKLC, whenever we spotted problems caused by the fact that the actual SGCAPS feature has the same limitations in it.

It works quite well for the small percentage of cases that it is actually used like in Hebrew and Swiss German, but really only because the developer who added it/owned it fixed those bugs when they were reported. The rest of the bugs just kind of stayed or that dev turned the abilities off as they were reported since no one needed them....

"Ligatures" in the keyboard sense are a good example of this kind of issue -- and my initial bugs were along the lines of "this works in MSKLC itself but not in the keyboard it created" and the tester's assumption that the error was in the keyboard creation step. This led to the "fix", which is why the 'ligatures in SGCAPS" feature isn't there in MSKLC now....

Unfortunately, "empty keys in SGCAPS" fall in that same category -- the way SGCAPS is defined in both MSKLC and the underlying keyboard architecture is on a per-key basis by defining a letter in the SGCAPS state.

Now my particular "dev" effort here was mostly as much of a cowboy programming exercise as the underlying SGCAPS feature was way back in the early 90s, and the problem with both is that without a spec and a test plan it is too easy for development to add features that aren't thought through in an end-to-end way. It leads to problems like ones mentioned in blogs like SGCAPS and dead keys don't mix and Just one code point for SGCAPS...., and of course the underlying limitations as well.

In fact I am lucky that there was one VERY real fact I could not ignore reining me in here: keyboards being built were working as far down as NT 3.5, and no one was going to let me fix things in those prior versions to add features. So if something didn't work, my job was to shut off an ability, not extend a feature.

Nothing like reality to rein in the creative urge of a would-be cowboy programmer!

And still it continues. Just the other day another comment came up, from reader Ad Caweau in this blog:

A workaround could be to use the SGCAPS feature of MSKLC and replace the "CAPS LOCKed keyboard" keys with the standard QWERTY-layout.

This way you reprogram the CAPS LOCK key to be a QWERTY LOCK key.

It works easier and more reliable than the standard available keycombination and you can tell by the CAPS LOCK LEDs whether QWERTY or Dvorak layout is active.

It astonishes me every time I see yet another "off-label" usage of SGCAPS (up to and including this one!), and although off-label SGCAPS usage consequences are not nearly as potentially bad as can be with pharmaceuticals, the fix is the same when you run into problems -- stop going so far off the intended usage!

Sorry it took so long to write this one up Szabolcs (if you're still around!). Perhaps this will at least provide a little closure on why it wasn't working the way you wanted.....

John Cowan on 7 Jul 2010 9:12 AM:

Michael S. Kaplan on 7 Jul 2010 9:43 AM:

Random832 on 8 Jul 2010 4:42 AM:

Michael S. Kaplan on 8 Jul 2010 5:03 AM:

referenced by

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