I am going to break the system into these components:
-> One program for each input method that does the translating:
one for Attic, one for German, one for Japanese, &c. Each of these
should be pretty straightforward to do.
-> A program that presents as a filesystem the control interface
for switching between methods and for showing the onscreen
keyboard. It will direct the keyboard input to the currently
selected translating program. This will be done for each
window. I'm thinking that it'll be easiest if this part is
integrated into rio, but there are other options. In addition to
the fs interface, it will optionally be controllable by keyboard
shortcuts.
-> A small GUI widget that shows the available input methods and
a window listing. Rather than using the control fs directly, the user
will use this. It will sit unobtrusively in the corner of the screen
when it isn't being used.
-> The virtual keyboard. It will display the active keymap on
its virtual keys. It will also serve as a GUI for more complicated
input methods. For example when using Japanese input, it will display
kana-kanji translation candidates.
Is that what you meant by implementation strategy?
--
You received this message because you are subscribed to the Google Groups "Plan
9 Google Summer of Code" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/plan9-gsoc?hl=en.
