Recently in GSoC Category

August 8, 2010

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

copy.png
paste.png
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,
        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.

phonepreedit.pngWith 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 :)

customtool.pngCustom toolbars! I really overestimated the difficulty of this. Turns out, a custom toolbar is just a plain xml file which looks like this:
<?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.

June 22, 2010

So the input context skeleton is finally in place, and gedit can start receiving commit signals from the MeegoTouch keyboard:

initialcommit.png
I can even create new documents and switch tabs while typing on it, and it correctly follows focus. Not much else to try yet!

Many thanks to murrayc for Multipress Input Method, from which I took many build system related bits and of course to Mohammad Anwari for the original Hildon Input Method.

May 23, 2010

Hello everybody,

I've been selected, as part of the Google Summer of Code project, to work on what will become a Gtk+ Input Method that communicates with the MeegoTouch (previously, Direct UI) Input Method UI Framework.

Basically, input methods either modify or completely replace the flow of characters from your keyboard, keypad,... to whatever applications show in their input fields. They can be either virtual keyboards, thus generating key events on their own, based on mouse input; they can filter some of the key presses on your physical keyboard to allow you access to way more characters -- for example, the "acute" character on some international layouts doesn't produce an acute symbol, but instead combines with the character the next key would produce to form an entirely new character. Of course, you can use both approaches, and have something like the hardware keyboard with symbol palette that the N900 uses, or even way more complex things.

So, when I realized that the next version of then-Maemo6 was going to use a new, Qt-specific input method framework, I knew things would look bad for Gtk+ applications on the platform. If you've ever tried any non-Gtk+, not-Qt application (DOSBox, for example) on the N8x0, or N900, you know what I'm talking about. This is something that would kill usability of most existing Maemo Gtk+ applications, and not only for international users. Clearly, fixing this is quite an important TODO item.

Also, I had already been experimenting with trying to integrate the Maemo-5 input method framework (known as Hildon Input Method, or H-I-M) with SDL, so when I looked upon the idea, I knew this was going to be interesting.
But this is not all -- Harmattan was being slowly cooked in the open, and I was practically ignoring it. MeegoTouch, Qt, etc. is without doubt going to replace most of what I currently know and use, and thus I'm really interesting in getting the hand of it. So I also see this project as an oportunity to get used to the entire stack.

So what did I do first? Well of course, try to run everything.

imframework.png
Above you can see the widgetsgallery you can download on your N900, but a bit more recent and also not Maemo 5 but Debian Squeeze on an amd64 host (so I already had to patch some components :) ). Also running is the MeeGoTouch IM UI Server, with the MeegoKeyboard plugin active. Pressing keys on it does what you expect. Typing keys on the hardware keyboard results in some D-Bus messages from the client application to the IM Server -- again, similar to what you'd expect from an input method!
customtoolbar.pngBut hey! The MeeGo IM Framework seems to have some unexpected nifty features, at least when compared to H-I-M. This made me think about Gtk+ widgets in there. Sounds hard -- but definitely worth reading about.

Of course note that this is using the development theme, and also I was not using the MeegoTouch compositor at the moment, so no translucency goodness: the final UI should look much prettier.

Well, the official GSoC start date is tomorrow. I plan to use this blog to put in news, development progress (hopefully biweekly) or interesting tidbits I discover from the entire MeeGoTouch stack. See you until then!