by Michael S. Kaplan, published on 2015/06/16 15:27 +00:00, original URI: http://www.siao2.com/2015/06/16/8770668856267196499.aspx
Link to previous part here.
I'll start from fictional genius sociopath Hannibal Lecter's lecture:
Hannibal Lecter: First principles, Michael. Simplicity. Read Marcus Aurelius. What does it do, this tool you seek?
Michael: It builds complex input methods.
Hannibal Lecter: No, that is incidental. What is the first and principal thing that tool does? What need does it serve by building potentially complex input methods?
Michael: Anger, um, social acceptance, and, huh, sexual frustrations, sir.
Hannibal Lecter: No! It builds keyboard layouts. That is it's nature. And how do we begin to build keyboard layouts? Do we seek out keyboard layouts to build? Make an effort to answer now.
Michael: No, we just...
Hannibal Lecter: No, we begin by building the keyboard layouts that we build in every build of Windows.
MSKLC (Microsoft Keyboard Layout Creator) is a somewhat elaborate tool with a deceptively simple purpose. While the other keyboard layouts like the integrated ones in Windows or the ones in Windows Phone use XML files with particular schemas, MSKLC uses the same text files that have existed since NT 3.5 and earlier, always postponing the"feature" of an XML source file as gratuitous since Windows has always built keyboard layouts without any such fripperies, bells, or whistles. So why should MSKLC do anything any different?
Now the user interface used Windows Forms, and even though people would ask me over the years why it didn't use WPF (Windows Presentation Foundation) or Silverlight I would politely or not so politely remind them that (a) MSKLC is built in the Windows daily build and (b) neither of those two technologies even existed until after 2006 or 2007 and that even if they had existed when MSKLC 1.4 was being released that nobody was approving a budget to rewrite the user interface in a new technology. The mantra of minimal effort was drilled into the entire project regularly.
Things first changed with the ARM release of Windows described in Part Two since although MSKLC was approved for ARM-based tablets, Windows Forms user interfaces were not. So although the setups and the underlying kbdutool.exe could nominally be built for ARM, the user interface couldn't, and that rewrite of the user interface would finally after almost a decade be required.
The fact that the combined needs of tap and hold and chained dead keys (as described in Part 4) required thinking about a new user interface paradigm was fortuitous window dressing since working properly for Windows tablets and even dare I say Windows Phones was going to require a rewrite of the user interface anyway. So why not just take advantage of the fact that circumstances were all seeming to intersect and call it kismet?
As it turns out, there is another way to describe when everything happens to intersect and that is the Bermuda Triangle.
So the rewrite of the user interface is required for the ARM platform and the updated use of an XML based source file as an option as an optional feature would make a Windows Phone based update more optimal. If only someone would approve the update, MSKLC would be able to finally be able to move forward....
# Jan Kučera on 2015-06-17 03:03:55:
# Michael S. Kaplan on 2015-06-17 06:12:05:
referenced by