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