So the deadline is approaching, and slowly all features start appearing:

Pretty much like the way you could on Maemo, the virtual keyboard allows you to copy/paste from it (see the buttons on the top right corner -- prefixed with !! because of an error with my i18n setup). This now works with Gtk+ apps too, even with a stock/nonHildon Gtk+, as long as your text widgets implement GtkEditable or are subclasses of GtkTextView (gedit is the latter).
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,
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 :)
Custom toolbars! I really overestimated the difficulty of this. Turns out, a custom toolbar is just a plain xml file which looks like this:
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:
When the widget gets focus for the first time, the filename is sent to the input server, which parses it and creates the Qt widgets for you -- afterwards, you can still modify certain attributes of the toolbar, like whether buttons are pressed down or not. Unfortunately, I couldn't find a nice way to design a equivalent API for this in Gtk+, so for now you can only attach toolbars but not modify them. A sane API should implement at least a new class for this and so far I'm don't think defining new classes in a IM Context Plugin is the right way.
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.
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.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE MEEGO_IM_TOOLBAR_WIDGET SYSTEM 'VirtualKeyboardToolbarDTD.dtd'>
<toolbar>
<button name="buttonsmile" group="buttonsmile" priority="1" showon="always"
alignment="left" icon="/usr/share/widgetsgallery/imtoolbar/icons/icon-m-messaging-smiley-happy.svg"
size="80%" text="" text_id="" toggle="false" pressed="false">
<actions>
<sendstring string=":)"> </sendstring>
</actions>
</button>
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();
g_object_set_data (G_OBJECT (entry), "meego-im-toolbar",
"/usr/share/widgetsgallery/imtoolbar/exampletoolbar1.xml");
When the widget gets focus for the first time, the filename is sent to the input server, which parses it and creates the Qt widgets for you -- afterwards, you can still modify certain attributes of the toolbar, like whether buttons are pressed down or not. Unfortunately, I couldn't find a nice way to design a equivalent API for this in Gtk+, so for now you can only attach toolbars but not modify them. A sane API should implement at least a new class for this and so far I'm don't think defining new classes in a IM Context Plugin is the right way.
Leave a comment