Windows keyboard restrictions
marc at keyman.com
Sat Aug 8 15:46:14 CDT 2015
Richard Wordingham <richard.wordingham at ntlworld.com> wrote:
> On Sat, 8 Aug 2015 17:05:26 +1000
> Andrew Cunningham <lang.support at gmail.com> wrote:
> > Michael did do a series of blog posts on building TSF based input
> > methods years ago. Something I tinkered with off and on.
> Does this mean that one can put it all together from his reconstituted blog? I
> don't know how much was salvaged. Michael has publicly complimented Marc
> Durdin on being able to find his way through the published Microsoft
> documentation to make TSF work for him once Microsoft had fixed the bugs he
> had identified.
The TSF documentation is definitely sparse and there are some real challenges in getting up to speed with what is a very complex API. But the real challenges in input method implementation come more from the vast array of interpretations of how keyboard input should be consumed by Windows apps, and the extremely patchy support for TSF (and "foreign" language input) in apps. That's where I've killed thousands of hours over the last 15 years; once you get your head around the TSF model it's not too hard to code to.
Clearly, you've seen some of the same compatibility problems with KMFL. And our experiences on Mac OS X, Android and iOS are much the same. For example, Norbert Lindenberg's excellent blog on developing keyboards for iOS details much that is missing from the API docs: http://norbertlindenberg.com/2014/12/developing-keyboards-for-ios/
There is a massive cost to developing -- and maintaining -- a native code input method for each language and each OS. I'm really trying to minimize this cost with Keyman Developer 9. Keyman Developer 9 is a free product (http://keyman.com/developer/). It is currently in beta but is relatively stable.
More information about the Unicode