So the deadline is approaching, and slowly all features start appearing:
Even if there’s data available on the clipboard, and text selected in a window, only one button appears (so you can’t select text and replace it with the clipboard contents). This seems to be an arbitrary UI decision.
The MeegoTouch IM framework has different layouts for each “content type” a text field can handle — something equivalent to hildon’s InputMode property. Since there’s no “standard” way that I know of for Gtk+ applications to send “hints” about content type to input contexts, other than setting up different GtkIMContext subclasses for each and every configuration and then setting a widget’s “im-module” property, I decided to use g_object_set_data / get_data for hints. For example,
GtkEntry *entry = gtk_entry_new(); g_object_set_data (G_OBJECT (entry), "meego-im-content-type", GINT_TO_POINTER (MEEGO_IM_CONTENT_NUMBER));
Hildon used a new property (“hildon-input-mode”) which was defined in GtkEntry, GtkTextView, etc. Of course, when building with the patched Gtk+ you can still use it.
With content type set to “phone number”, the layout presented is certainly interesting because one of the buttons does not generate text instantly: the “*+” button cycles between *, +, w… each time you press it (aka “multipress”). Works too
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE MEEGO_IM_TOOLBAR_WIDGET SYSTEM 'VirtualKeyboardToolbarDTD.dtd'>
<button name="buttonsmile" group="buttonsmile" priority="1" showon="always"
size="80%" text="" text_id="" toggle="false" pressed="false">
<sendstring string=":)"> </sendstring>
Each widget can be associated to a different toolbar — for example, the way I decided for now to allow to do this in Gtk+ is:
GtkEntry *entry = gtk_entry_new();VN:F [1.9.22_1171]