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 <[EMAIL PROTECTED]> 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 >
