Questions on writing an input method

[Claes Mogren]

Just a question, have you taken a look at
http://live.gnome.org/Hildon/HildonInputMethod ?

I downloaded the sources and tried to get it all to build natively but that
was as far as I got. It looks fairly sane to me, and maybe good enough to
contribute to instead of starting from scratch.

My hope when I tried to get it working was to see if I could get some kind
of HexInput method working, especially with different char layouts.

Regards,
 Claes

On 10/15/07, Derek Pressnall <dpressnall at gmail.com> wrote:
>
> Since there has been a lot of discussion on input methods, I thought
> I'd take a crack at writing my own.  Actually I was thinking of
> putting together more of a framework that multiple input method styles
> can be plugged into.  But I have a couple questions to get started:
> 1) How does the input method register itself to the openmoko framework
> so that it shows up as a valid user selectable method?  For example,
> on Qtopia, I believe it has to be compiled as a dynamic shared object,
> with specific functions / symbols defined, and then plopped in a
> particular directory so that it gets picked by the framework.  Where
> can I find documentation on how this is to be done in openmoko?
> I've looked at the included keyboard app, but it appears to be written
> as a regular X11 app and not using any gtk or libmokoui calls, and I
> can't find where it registers itself.
>
> 2) Does the current UI pop up the default input method automatically,
> or is it up to the user
> to bring up the soft keyboard manually? I can't tell  by looking at
> the code (last time I brought the code up in the emulator was previous
> to the 2007.2 changes, and haven't had much luck getting the current
> code to build -- problems on my end).
>
> 3) If the answer to 2) is yes, then can an app specify any preferences
> to the input method that is popped up?  For example if an app field
> only accepts numeric input, then it would make more sense to pop up a
> 10-key pad vs. a full keyboard.
>
> 4) How would the input method communicate the inputted data to the app
> -- does it have to use X11 specific calls to inject characters into
> the keyboard buffer, or is there (currently or plans for) a libmokoui
> call to deliver a character as input to the current app?
>
> 5) Finally, what which gtk widgets would be best used for building a
> screen keyboard?  One method would be to pack shaped buttons (each
> representing a key) into a box using specific coordinates.  But this
> would require that a key be pressed & released before the action is
> delivered -- the button widgets don't support clicking on one key and
> then dragging to other keys (or dragging to specific areas of a key).
> However it would be good enough for a simple pickboard input method.
> An alternative would be generating two pixmaps, one to represent the
> virtual keyboard / input area, and a second one to be used as a mask
> that identifies the various hot spots.  Then load the main pixmap into
> a gtk_drawing_area widget and grab the coordinates that are
> clicked/dragged on from there, and compare with the value at those
> coordinates in the second pixmap to determine which virtual keys were
> hit.  This would work perfectly for some of the more advanced input
> methods that were discussed (i.e. QwikScript).
>
> Note that I'm a fairly good C programmer but haven't done a lot with
> GTK yet.  However once I get the GTK basics down, I'd like to put
> together something that can be utilized as a clear reference input
> method app, so I'd probably lean towards code readability vs. making
> it the best possible.
> Also, I'd like to stick to GTK and libmoko* calls if possible, since
> it is possible that I might code up a version using a small
> interpreted language which I'm writing up GTK bindings for
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20071015/bd5ed3bf/attachment-0001.htm