Perception-IME - The features and pitfalls so far...

I should probably make clear that I have no prior experience with writing any form of Input Method Editor prior to beginning this project... Perception-IME is specifically limited to dealing with Keyboard Input to Unicode Glyph selection for presentation to Intuition as a UTF8 encoded Codepoint selection. However with that said...What I have done so far... I have written out a design sketch for functional parts, Implemented a shared library on AmigaOSv4 (I have several of these as skeletons now using common code for the main.c easily changed as required) Implemented a Process from within the Shared Library with single-instance exclusion, This was actually quite easy compared to the 68K edition of this trick which required compiler specific functionality. Implemented an InputHandler which also provides the first stage of Translations from Raw Keyboard Events. (this information is all passed through a CircularArray "RingBuffer") Now that the process (which also is a commodity presence and enabled/disabled by that means) is beyond registered and actively responding to keyboard events passed through the ringbuffer, My next goal is to link in active processing of the "_ANSI" and "_AMIGA" "TRANSLATE_" type marked events (I'm using semantic keywords from the open-source released code) I intend to make a LanguageContext registration and masking setup as my next step, Each "Language" will register with Perception-IME for any extended (non-latin) language support and will include a defined "Codepoint Range" from the Unicode standard. This will help in having a secured Input Plugin mechanism where each Language can "plugin" and make use of Perception-IME performing a multipass Hook call into the Language from its own process (input.device is unaffected). For any UnicodeRange definition a "LanguageContext" structure will be required. This will actually allow for KeyMap switching *AND* Translated Languages to work side-by-side without conflict (Anything Keymap.Library can Map from a Raw Keycode into a useful "VanillaKey" event may be 2nd-pass Translated by any Language Plugin selected as "Active" to edit what is Input from the Keyboard based on reducing the range to a given minimal user selection by popup menu based on the mouse cursor position. However as the design is as much a work-in-progress as the code, please expect this to only reflect my "current thinking" at the time of writing. The only additional step in addition to the above would be consideration for porting issues (I am considering portation about equal to a re-write at this time) Only AmigaOS system calls and any external functionality will need to be dealt with, everything else is internal and direct linked calling without any portation issues. 2014-April-16 (AbH) Belxjander Draconis Serechai, Jeremy Lee Kajikawa-Sutherland Both of the above names are one and the same person (and are a condensed form of multiple legal names based on paperwork in at least two countries now. So please don't insist on a single real name...it won't work and just makes things more awkward...*sigh*)

Tags: 

Blog post type: